Rasmus Seeberg is the VP of Engineering at iPaper. He built his first website at age six and built a browser-based game and gaming company at age 16. Rasmus is a certified scrum master and has extensive experience with a variety of technologies, particularly frontend.
We recently connected with Rasmus to learn more about the evolution of digital-first experiences from traditional print, his thoughts on incorporating user feedback into the product roadmap, and insights into how company culture impacts recruiting and retention.
Our conversation has been edited lightly for brevity.
iPaper has been around since 2006. We help customers all over the world replace or augment their printed catalogs with highly customizable digital flipbooks. iPaper originally started as a project built by a digital web agency for a specific customer. The agency later realized the product could work for a lot of people and spun iPaper off as its own business entity.
Today, iPaper has about 100 million unique sessions every month. We serve around 1.2PB of traffic from our CDN on a monthly basis and have customers across the globe — both end users and businesses. We have pretty big reach at this point. That’s cool because, with only 40 or so employees, we’re still a fairly small company.
Sure. Moving from paper to digital is influenced a lot by demographics, including geography and age. Younger generations are more into digital than analog. It also depends on the type of product.
For very expensive, high-end purchases, people usually want to go out and view the product in person and maybe get a high-quality brochure. So there is some part of the buying experience that can be hard to mimic in a digital environment.
There are environmental factors, too. In the EU, specifically, there are more and more regulated legislations around the type of paper and ink that are allowed. There are also regulations around distribution. A lot of people are opting out of catalogs.
Many large companies have a ton of processes built up around how they do print. For them, the transition from print to digital may take longer. But, over time, I think we’ll move toward more of a digital-first experience.
There were a few things that were unexpected! The new role was a promotion, but it was also a completely different job. I started out at iPaper as a senior frontend developer, then became the lead frontend developer.
I remained in that position for quite a while — helping out and making sure that the frontend team was running well. At that point, I still had time to code, and I enjoyed that. Then, I took over as engineering manager and now as VP of engineering.
Today, I spend a lot of time on high-level people management, making sure our overall development plans are in alignment from a product perspective, trying to balance technical issues with continued product focus, and making sure my team is happy. The surprise for me was how much time all of that takes. People management is super time-consuming.
I really don’t have time for coding anymore. At this point, the closest I get to coding is sitting next to others, helping with peer programming, and going over problem spaces at a slightly higher level. But it’s also a lot of fun. My new role provides me with the opportunity to touch more things.
iPaper’s core values are:
I actually struggle a bit with “Think big, start small,” and I think a lot of developers do. We think really big, and then we start really, really big. But fortunately, there are people here from a variety of backgrounds who can help us tone it down when we get too ambitious.
My favorite core value is “Act as a team, embrace the individual.” It’s really about accepting that we’re all humans. We all have individual needs, and our needs change over time. Some of our employees did not have families when they started here. Now they have kids and occasionally need to leave work early.
Sometimes life changes, and we embrace that. I think that’s a pretty unique perspective for a company.
I think the best bet for recruiting people who will be a good fit for your company is to be super honest and open about the work and your workplace culture — even if there are some things you think could potentially be off-putting to job searchers.
You never know what it is that people are actually looking for. Some people enjoy a more rigid workplace with daily tasks that are specced out six months in advance. Others like to have things more loosely defined. Different people thrive in different conditions.
If you’re honest about what your company’s conditions actually are instead of presenting what you believe a candidate would like, you’ll end up with much better matches. This also means your retention will be better. Honesty gets you quite far.
We try to be very honest about all of our company’s pros, and also those things that could be perceived as cons. For example, we’re not a remote company. We use a hybrid work model, but we prefer for people to be in the office. Our office culture is super important to us. Some people may see this as a negative — and that’s fair — but others prefer this work model.
Many of our employees are young internationals living in Denmark. They don’t have a strong social network here, so working at a company that places importance on spending time together offers tremendous value to them because it helps them build a friend group.
We have an extremely competent, friendly team working in our customer care and customer success departments. They make sure to collect feedback whenever they interact with our customers: What worked well? What didn’t work so well? What would you potentially like to see changed? What can we do better? Was there anything that was hard to understand?
They add this feedback into Jira’s Ideas tool so that we can track how many customers requested a particular feature. All of this goes into our roadmap where we can evaluate: Do we have the potential to make an improvement? What sort of problems would this change solve for our customers? Can we solve the same problem in a different way?
iPaper offers a variety of features that impact how digital experiences are generated and consumed. The input that we get from our customers is extremely valuable, but sometimes it is specific to their own use case. We need to consider that there could be many use cases out there.
It can be difficult to translate one customer ask into something that could work well for many different customers. It can actually be quite hard to gather customer feedback if you want to use it in a structured way.
Exactly — and also because the way customers use our system differs. We have direct-selling customers who use it as a browsing experience where consumers can view items online and then make a purchase with a local representative. We have customers who directly integrate us into their ecommerce.
We also have inspirational catalogs hosted through our platform. This scenario is very much about building an enjoyable online browsing experience that will translate to the consumer feeling inspired to visit the physical store to make a purchase.
These are vastly different use cases. So each of these customers will have a different idea of how iPaper could potentially be better optimized for their individual scenario. But tracking and monitoring all of this feedback helps us to prioritize where we put in our effort.
Sure. Many of our customer pages feature an image showcasing a large number of products, but they lack the data to tag it up properly.
For example, imagine a webpage with an image showcasing home goods products — things like carpets, pillows, and throws. You may want to offer a purchasing experience for these items, but not by injecting 25 buy buttons onto the page.
We had already started working on an idea to address this scenario, but we didn’t have any concrete examples of how it would be used, or whether it was something that people really wanted, until we started getting customer requests for this very idea.
We built functionality for customers to have many items visible on a catalog page and then open up an experience where they can quickly review details for all items on the page. This feature was the direct result of a customer ask; it tied nicely into the way we had already envisioned doing this, but we didn’t initially know there would be a market for it.
Another example relates to checkout options. Being a Nordic company, we tend to think of the checkout process as happening on a specific website. But that’s not the preferred option throughout the world.
A lot of our Latin American customers use mobile applications like WhatsApp for checkout. They send out an entire basket worth of items, from different websites, to the mobile app checkout. This was a customer feature request that we implemented, and it has turned out to be very valuable to a lot of people.
We tend to be very metric-focused, but I think metrics are easier for some things than for others. For example, we can monitor how well our product works pretty easily by looking at error rates, consumption rates, time spent, and other semi-basic metrics. If you have enough of them aggregated on a very high level, you can get a feel for whether you’re moving in the right direction.
We can use this data to see what happens when we make a change to our product. Does it impact the rate of consumption globally? Does it move our product toward the type of engagement we would like? We can easily measure and monitor these things. But when it comes to humans, metrics are really tough.
In terms of my domain — engineering — I need to make sure that our error rates are in order and that we don’t have downtime. But the most important aspect of my job is to make sure that our development team is happy, and that can be really hard.
One metric that people talk about a lot is productivity, but how do you measure productivity for a software developer? I honestly don’t have a great answer. Counting lines of code created is a really simplistic (and bad) way to measure productivity.
It’s also too vague — some pull requests take a ton of time to make, while others are super fast. Creating a large number of pull requests could result in small changes, whereas creating just one could solve a major business issue.
So how do you measure the productivity and impact of individuals? I think your best bet is to spend time with them, find out what they are working on, ask questions, and listen.
Ask: What are you working on? How is this task going for you? Are you enjoying the work? What would you actually like to work on? In what area would you like to grow? Are there things we could do to make work more fun?
Then, do your best to adhere to those wishes. Most of the time, I’m able to switch tasks up so that everyone on the team has something they find rewarding. Probably one of the best things in my new role is seeing that people enjoy coming into work every day — that’s the greatest feeling, really.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up nowLearn how to implement one-way and two-way data binding in Vue.js, using v-model and advanced techniques like defineModel for better apps.
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.