ProdMinds #1 — Maarten Dalmijn

Hello. My path into Product Management is unusual. I have no background in tech or business at all. I studied Biology and obtained an engineering degree in Functional Genomics at the Technical University of Delft.

2 years ago   •   7 min read

Merve Cankiz Coruh
Prodminds by Producter

ProdMinds is an interview series featuring product minds around the world.

Team Producter: Would you tell us a bit about you and your career path in product management?

Maarten: My path into Product Management is unusual. I have no background in tech or business at all.

I studied Biology and obtained an engineering degree in Functional Genomics at the Technical University of Delft. During my studies, I did research on genetically modified to compare migraine mice with normal mice. I discovered I sucked at doing experiments, and I realized the world of research wasn’t going to make me happy. I decided to try something completely different after university.

My first job was as a Marketing Manager at a healthcare start-up, making a health checks for the general population. I loved that job because I was wearing many hats and was closely involved with the product. I was working daily with developers and UX designers to build cool things. My manager told me he thought I’d be a great Product Manager and he’d like to promote me to that position. I was elated and thought it would be the perfect fit for me. Unluckily, the 2008 crisis hit, and I had to find a new job.

I knew I wanted a job in Product, but nobody would hire me. In fact, nobody would even hire me for a marketing job, as the job market was flooded with candidates with more experience than me (and a marketing degree to boot). When I did get invited, which was rare, they would actually ask me why an engineer would want to work in marketing and the conversation would go downhill from there.

I actually decided to work as a Software Tester, as that market was super scarce. I got hired and quickly was promoted to Senior Test Engineer in a few years. I also started being a Scrum Master on the side. Then I became a Business Analyst and used that to get hired at a start-up to become a Product Owner.

I took many different stepping stones to end up as a Product Owner. I faced hundreds of rejections, but in the end, someone believed I would be able to do the job. After I landed the first Product Owner job, I knew I was hooked. I love the complexity of Product, and how there are still many areas where I’m a beginner.

It’s been a long and difficult journey, but now I’m the Head of Product at a start-up. And I’m learning a lot of new things, as what made me good before isn’t what makes me good at my job now. It’s more about fostering an environment where great products can be built rather than doing it myself. It is an entirely different ballgame.

Team Producter: Which part of being a Product Owner is the most challenging for you?

Maarten: Keeping stakeholders happy while you’re not giving them what they want.

People always want more than you can deliver. Different departments have different perspectives on what will bring the most value to the Product. When you work in Product, you’re at the center of that conflict, and it’s your job to manage that tension successfully. It’s incredibly difficult to manage that tension well. You either cave in and dilute the value of your product, or you don’t cave in the wrong way and you put the relationship at risk, which often comes back to haunt you.

What makes it challenging is the constant stress and because it is easy to get frustrated by all the requests and demands. You have to stay positive, no matter what kind of requests you receive. Early in my career, I would get requests I thought were not smart, and I’d immediately respond in a way they’d notice I thought they were inadequate. This approach would backfire, as I’d not give people what they want, but I’d also make them feel bad about it, and they would remember, and make my life difficult later.

As I gained more experience, I cared less about being right but more about doing the right thing. I also learned the importance of leaving the door open for doubt, you could be wrong. I now often try to think, how can we test this assumption in the simplest possible way so my opinion doesn’t matter. We can find out what matters by encountering reality instead of speculating.

Team Producter: How do you think departmental silos affect product companies? In what ways do you build and maintain relationships with stakeholders from different teams?

Maarten: I think there are enough topics of contention between the world of Product Management and Scrum (e.g. What’s the difference between a PM and a PO?). I believe the world of PM and Scrum do agree on the importance of empowered teams.

When you do complex work, empowered teams (self-managing in Scrum terminology) are necessary to deliver the most value. Our plans will be imperfect, people won’t execute tasks exactly as expected, and even if they do, they won’t produce desired results.

Short feedback loops are of the essence in such a complex environment. Disempowered teams mean you have long feedback loops, and you won’t be able to iterate toward the desired result quickly.

With stakeholders, don’t try to manage them. Try to include them in your world and get them to include you in their world. Making someone feel seen, heard, and respected is a large part of the job. You can’t do that unless you understand their world and what they care about.

Team Producter: When it comes to listening to your users, what’s your method? Is their input considered in critical product decisions?

Maarten: Listening to users is something you develop over time. I actually think listening is not the right way of putting it. Observing your users makes more sense to me.

You try to understand where they are coming from, and the important thing is to always keep in mind the difference between declared preferences vs. revealed preferences. What people say they want is not necessarily what they actually need.

This doesn’t mean you shouldn’t listen to your users, but you should try to understand what they are trying to achieve / how they actually work. That’s far more revealing than asking them to come up with a conclusion that you can’t tie to what they actually are doing or trying to achieve.

Here’s a great quote from David Ogilvy that sums up the mystery of asking people what they want really well:

“Consumers don’t think about how they feel. They don’t say what they think and they don’t do what they say.” — David Ogilvy

So yes, user input is considered but asking what they want directly is risky without understanding their way of working.

Team Producter: We continuously iterate and improve our products — sometimes, it becomes challenging to keep everyone in your organization and users updated on what is new. How do you communicate product updates both inside and outside your organization?

Maarten: We often use Slack and I sometimes make videos to share product update videos. This is mostly internal at the moment. We’re working to do a better job at sharing product updates outside the organization. We also share what we’ve done at the Sprint Review regularly.

Team Producter: Is there a method you use for prioritization? Or, Is there a custom approach you designed?

Maarten: I’m not in favor of prioritization methods. They can distract from what matters and can provide a false sense of value certainty. We often don’t know how valuable something is before we start doing it, and we also don’t know how much time it takes before we do it. And if that’s true, aren’t we just wishfully rubbing our crystal ball in the hope that shuffling noisy things around will result in delivering more value?

A much more sensible approach is to prioritize based on your goals or outcomes, and do small experiments to move the needle on those outcomes. You prioritize based on the value of your goals, not based on your flawed assumptions on how well you can deliver on those goals.

The reason many companies don’t do this is that you need to have a model of how you are delivering value with the different outputs and how they are driving outcomes. Staying in the realm of features where we believe feature X will deliver value Y is far easier, even though we’re often just fooling ourselves.

A good place to start is the North Star framework, as it’s a simple model to get started with and forces you to make explicit how different aspects of value delivery relate to your North Star. The constellation of inputs is basically a giant hypothesis tree of the different ways your product delivers value to users.

Producter is a product management tool designed to become customer-driven.

It helps you collect feedback, manage tasks, sharing product updates, creating product docs, and tracking roadmap.

👉🏻 Sign up Producter for free


You may also like:

ProdMinds #17 - Jason Knight
In all seriousness, it’s a great job but it’s often hard to feel you’re making an impact. I was a really strong individual contributor earlier in my career, and it took me a long time to let go of the fact that I wasn’t being measured on output anymore.
Prodminds #12 - Graham Reed
Product Management is also a unique role, and with it’s unique challenges, pressures and pitfalls.

Spread the word

Keep reading