“Outcome-thinking is difficult.” Agreed. I noticed how often we fall into the trap of thinking that we talk about outcomes when we actually talk about outputs. So I have to steer the conversation back to real outcomes, especially in outcome-based ideation or discovery sessions. 👉 But what is an “outcome” anyway? And how do you realize if you’re thinking in outcomes or outputs? Here's a mini series on detecting output-thinking and finding outcomes. These are two of my LinkedIn posts with links to the original post, as asked for from my followers to find it when they need it.

My first ever yearly reflection. On a new life as a solopreneur, mother, and partner. And introducing to you my habit of picking a word for the year. This year it's "Focus". Here's why.

Let’s be honest. We’re stuck in output focused conversations way too often. The management team knows exactly which features to build next. …

During a Clubhouse session I received a very interesting question. As I'm at the same time a no-code maker, the question was if we still need to think about whether we should build a feature or not, now that the no-code movement made it so easy to build features and entire products. Here's my answer.

In many calls I notice that product people seem to shy away from analytics. I was wondering why. I had an eye opening chat about this with Henry Latham. We noticed that analytics is difficult when you don't know how "you get there". But when you have a thinking pattern to follow and a cheat sheet at hand, (product) analytics becomes much easier. Therefore, I have shared 9 practical tips every day on LinkedIn, based on hands-on experience that will help you get started. This is the collection of those 9 tips.

In this video - co-created with #PoDojo - I'm showing (yes showing, not only talking about) the tools that have supported me in my product work in a remote setup.

When you start out building a new product, you might think that having an idea and building it immediately is the direct way to success. In my entrepreneurial journey and as an ex-product manager I can tell you from experience that most of the time it's not. Instead, there are 4 areas that you should think about and validate those where you need some more information about. Here are some details.

Recently I had a great conversation with Iulia Jacobsson, Head of Product at Beekeeper, about product value. Our conversation started with the question: What is a Product Manager responsible for? The answer seemed quite obvious: A Product Manager is responsible for creating value to customers in a way that it supports the business. But talking further about it showed that it's not so easy to draw the line in the daily business. Where does our responsibility start and end? Here's how we went further down different areas of value creation and what a Product Manager is responsible for.

Culture-fit is crucial for both productivity and happiness - of the company as well as of the individuals. Every individual has different preferences and expectations on culture. Some people want to work in a hierarchy-free, open and collaborative environment that gives you space for taking over responsibility. Others feel better and safe working in hierarchical environment where someone on the top makes the decisions and tells them what to do, and they on the other hand play the power game. You'll have noticed now that I'm a fan of the former but I know - and find it okay - that many people feel more comfortable with the latter. And there are even more types of cultures but let me keep it simple with the self-organized and collaborative "new" way of working vs. hierarchical "old" way of working. The point that I want to talk about is not which culture is "better", anyway. I want to talk about what happens when you work in a company culture that doesn't match with your preference and the way you like to work.

Recently I had a nice little conversation with a fellow Product Consultant Julian Wild about MVPs - Minimum Viable Products. He asked me what I think about MMPs - Minimum Marketable Products. From there, we got into Minimum Usable, Testable and Sellable Products, and agreed that MxPs are handier in practice than MVPs and MMPs. And that you can apply the concept of MxPs actually to any adopter group whenever you want to tackle the next growth phase. Here's my detailed answer.