Post

The most sincere transformation is the one that you don't call "transformation". It's not a project with a start and an end. It's not kicked off by a ceremonial speech in front of your team. It's doesn't happen by following a given set of rules. It's when the whole team knows that great things happen when you collaborate towards common goals with a shared vision of a better future. This conversation between Jack Berglund, ex CPO Doodle, and me, one of the ex Lead Product Managers Doodle, is a reflexion of the time of transformation in 2017, the challenges, the benefits, and learnings in hind side. It's an open conversation, free-stlye, as usual no preparation and no edit.

An Agile Coach approached me and asked me for reference documents or people to share with him. He wanted to gather some examples on agile roadmaps but it was difficult for him to find good examples of agile roadmaps. Most of the examples that he found were far from agile. Here's my answer.

My second ever yearly reflection. I'm reflecting on my life as a solopreneur, product management trainer, and myself as a human. And revealing my word for the year 2024.

I was very skeptical about Product Ops. I couldn't grasp it. What's Product Ops anyway? What do Prod Ops Managers do the whole day? Why do we need yet another new role and even a whole new team that does things that we've been doing without them the whole time? Aren't we sick of creating new titles for old concepts? UNTIL.... I talked to Chris. Chris Compston. Check him out! Hi Chris. Thank you Chris. Chris is my best friend now. Sorry old best friends, you've been pushed aside (you are not but you know I need the dramaturgy).

Eine weitere spontane Aufnahme eines Gespräches, dieses Mal mit Julia Wissel, Director of Product at MOIA. Wir haben über Bäume generded und sind uns einig, dass ALLES im Grunde ein Baum ist. Und als wir dann bei unserer Begeisterung für KPI-Trees waren, musste ich auf Aufnahme klicken (natürlich mit ihrer Erlaubnis).

A few weeks have passed and I am still being asked what I think of the announcement Brian Chesky made at Config 2023. I waited some time to get more details about the change, and let's be honest at Config 2023 he only speaks about one part of the change but not about details. His announcement regarding the Product Management function and role also was not very clear. He used their internal wording and didn't think about the how the listeners would understand it. What is a "function"? I'd say it's the department in a big company, or team as in org function in a small company. But not the role and the discipline itself. He mentioned it in a tweet as well that he "should have been more clear":

While we are all aware by now that a good product strategy needs to create focus, we stopped talking about focus when we get into execution mode. When have set our focus in our product strategy but go all over the place when executing on the product strategy, we will not build successful products. We need to ensure that we keep focus when we execute on the product strategy. Therefore, whenever we make prioritization decisions, we need to start from strategy and work our way down to the backlog level through a cascade of decisions. I ran an in-house talk where I talked about "Strategic Prioritization". After sharing a screenshot of my slides...

Niko Noll und ich tauschen uns immer mal wieder aus zu Themen wie Produktmanagement, Solopreneurship, unsere eigenen Produkte, unsere eigenen hands-on Erfahrungen, Coaching, Interim, ..... und überhaupt :) Dieses Mal haben wir spontan auf den Aufnahme-Knopf gedrückt, als wir gemerkt haben, dass das Thema, über das wir gerade sprechen, auch für andere Product Manager und Product Owner sein könnte.

There are wonderful collections of prioritization techniques out there that you can read to learn about the most popular techniques and how they work. My favorite two collections are one from Folding Burritos and one from Productboard. This collection is meant to give you some tips that are based on my real-world application of these techniques, some background info that you might not know, and show you some more techniques that you might not know about yet (at least in the context of prioritization). Let's start with two techniques that you have for sure heard a lot about already, and then raise the bar little by little.

Data analysis learning: Know your universal set. In our case your user segments. Background: Recently I mentioned on LinkedIn that I had unsubscribed from Netflix because they keep killing series after season 1 or 2 with a cliffhanger, and I don't want more cliffhangers sitting in my head. Here's the original post. Netflix is known for making decisions based on numbers. I don't want to argue on their numbers, obviously I don't know their numbers. But some arguments under my post made me decide I want to make aware on the bias that sneaks in when we forget to closely look at our universal set.

This is another mini series that I had posted on LinkedIn.

n one of my LinkedIn mini-series I laid down how you can find meaningful outcomes with the 5-Whys, how the outcomes cascade that you can create with this method

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.