Lars Rieger is Head of Product at Digistore24 DACH, a digital reselling and affiliate marketing platform. After beginning his career as a project manager at Digistore24, he spent his first five years at the company and eventually got promoted to a lead product manager. From there, Lars joined CarOnSale’s product team, where he was responsible for payments, invoicing, and logistics, before rejoining Digistore24 in 2024.
In our conversation, Lars talks about the importance of relationships in product management and how they’re all about investing the time and personally caring about your work. He discusses his approach to leading a company-wide digital transformation at Digistore24, as well as how culture and ways of working played a large part in its successful adoption.
It’s always interesting when people come back from another company; there’s always a story behind it. When I originally joined Digistore, there were around 15 people, and when I left, it had grown to closer to 150. When you join a company when it’s small, it’s unlikely that you’re able to stay over the years and go through that transformation without building a personal relationship with the company, its product, and success. You also build close relationships with colleagues along the way.
Even though I left Digistore for two years, I still had personal connections with people at the company. I stayed in the loop on what was happening and still cared a lot about where the business was going. After some leadership changes, I saw signals that the way they did things before was not how they wanted to continue. There was a lot of uncertainty around how it would move from there.
I was working at CarOnSale at the time, and I recommended an engineering leader from the company as a potential consultant for Digistore. I knew that if anyone could help with their turnaround, it would be him. They really liked what he had to say and the direction he envisioned, which gave me the feeling that Digistore was heading in the right direction. After some time, I transitioned back.
In terms of a mindset shift, I learned a lot at CarOnSale. Leadership was very mature and experienced, so I got to see the behind-the-scenes efforts of product leadership specifically. I watched how they managed dynamics and created strategic clarity and alignment. Those are all essential for successful product teams, and it was great to learn from them.
The first big challenge is that you’re starting from many years of an old process. That shows in different places. For example, you’ll notice that stakeholders often have years of frustration from working in the old model. For teams, they’ve worked a specific way for a long time. They’re used to the old culture, and some people jump on the change. Others, however, feel a lot of resistance to modifying a running process. Those are some challenges to deal with right off the bat.
Further, there’s a whole organization to shift and transform. One issue that I underestimated coming into this experience was the leadership vacuum. That existed heavily across IT and product. We had a lack of strong PMs and didn’t have tech leads or engineering managers. There’s only so much one person can drive down into a broad organization. You need these middle layers in between to drive change through the teams and cascade down. We had to find and hire those people, which slowed down the speed of change on a broader scale.
Also, culture was an important point. The old model lacked a culture of ownership and empowerment, but it was much disempowered. In changing that for everyone, we had to cascade down a new definition of what it means for them to be successful and a new way of working. Is something done because we’ve completed the task, or is it done because we’ve actually solved the real problem? That takes getting used to.
The first piece is not as much about technology, but culture and way of working. For sure, one key component was hiring the right people, such as finding good engineering managers or promoting talented people from the existing team. We knew we needed to have the right people in place to drive something forward.
In terms of ways of working, we thought about how we could decrease loops within the team. How do we involve developers early and give them a better sense of ownership? How do we change communication with stakeholders and promote cross-functional communication? It took a lot of small tweaks in how we could better involve people, give them more responsibility, and not overwhelm them at the same time.
Our goal was really to break up that IT model and give people the right exposure so they could start thinking about outside impact. They developed a lot of problem and solution ownership as a result, and that was what helped this project propel.
I had to accept the underlying constraint that we cannot do everything great at the same time, and we cannot fix all parts of the organization immediately. When I came in, a lot of my time was spent on deeply understanding the different stakeholders, their needs, their pain points, and where the biggest friction was. From there, we could identify the areas where we could have our first big wins to showcase momentum.
We don’t have to show that everything is suddenly perfect, but if we can show meaningful progress on a few critical problems, that drives trust. People will be able to visibly see that we’re moving in the right direction.
For example, we had one extremely unsatisfied team, so we focused on addressing one or two critical pieces of their group that had been going poorly for a long time. Now, they’re some of the happiest stakeholders in the organization. We identified that one well, and it’s a great case study for moving forward with what we can continue to achieve.
Another notion of momentum is transparent communication and updates on progress. Previously, in the IT project model, stakeholders were all split up with a large degree of separation and at arm’s length from product and IT. Breaking down that wall and being extremely proactive with communication was crucial. That goes from senior leadership all the way down to teams interacting and PMs talking to their stakeholders. The more proactive communication and transparency, the better. Good communication solves so many issues.
There’s a nice aspect to not having years of formal, structured studying. You can get too theoretical in your thinking with a traditional education and focus on a certain way of approaching things. This is why, for me, the notion of beginner’s mind was always a strength. Be humble and be curious. I always remind myself that I don’t know best.
When we talk about leading people and growing, there’s also a level of openness to being wrong and learning from others. It’s easier to be receptive to being corrected when you don’t have too many formal processes squeezed in your mind already. Take Marty Cagan or Shreyas Doshi, for example. They talk a lot about how you have to have the right frame of reference, principles, and values rather than frameworks. Be happy to ask questions that other people might not want to ask. Those are all very important.
My time has changed a lot over the years, so it’s very dependent on situational context. Earlier in my PM role, I was on a team that was extremely heavy in a customer-facing B2B SaaS product. We collaborated closely with design and had a lot of complex interface workflows. In that case, it was extremely valuable for me to do the Nielsen Norman Group training and learn about user empathy, research skills, validation, etc. I needed to know that when we built complex workflows, we reduced as much risk as possible in developing things we don’t need. That was extremely useful.
When I was maturing as a PM, I eventually got familiar with Marty Cagan and thought about how online resources could help me. There is a different level of depth and attention to do a workshop or training instead of an asynchronous course, so that depends on what you’re looking for.
As a broader principle, I believe that credentials are relevant, but true experts with experience make a difference. I don’t believe in generic coaches or the like, but I do think people like Marty Cagan and Shreyas Doshi have tremendous experience in product. I look up to those people who have been there and done that. They have the practical experience to back up what they teach.
Finally, when I look at my team members, there’s no one-size-fits-all training. One person might need to be trained in a specific area to fill a gap, while the other might need to go deep in another because it’s a strong suit of theirs.
Two things come to my mind. One is to question your methods of communication. People can sometimes get caught up in thinking that they’re currently doing X or Y things to communicate, and that’s good enough. You have to actually step back and ask, “Well, I am doing that, and I can say on paper that I have fulfilled all requirements. The information is there and has been delivered. But are they really receiving it?” It’s important to recognize when a specific communication channel doesn’t seem to be working.
If something isn’t working, how can you find different ways of communicating and broadcasting for various topics and people? Maybe with one person, I can have Slack updates, and with another, they prefer jumping on calls. That piece is always useful — be open to questioning yourself and your approach, and identify what you can do differently.
Second, it’s all about relationships. If you’re a PM, especially, relationships are all about investing the time and caring. It’s easy to say, ” I have talked about important things here and there,” but you actually have to go the extra mile, take the time, set up coffee calls, have conversations with people, and get to know them personally. Get to know their challenges and their teams. Don’t look at the relationship as transactional — you don’t build connections that way. You have to personally care.
We sit at the intersection of the product and the operations around it. At the end of the day, the product is a piece of software, but there are also lots of servicing parts to it that make up the overall experience. At Digistore, for sure, a huge part of it is that the product is not just whatever we have in software. It’s also the interconnection between account management teams, support, sales, and all these different functions that are in close contact with our top clients, affiliates, and vendors. We focus heavily on how we can make that overall experience, including these manual and human touchpoints, smooth.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Rachel Bentley shares the importance of companies remaining transparent about reviews and where they’re sourced from to foster user trust.
Michal Ochnicki talks about the importance of ensuring that the ecommerce side of a business is complementary to the whole organization.
Christina Valls shares how her teams have transformed digital experiences at Cedars-Sinai, including building a digital scheduling platform.
Red-teaming reveals how AI fails at scale. Learn to embed adversarial testing into your sprints before your product becomes a headline.
Learn more →
