Product Model First Principles: Product Discovery, Product Delivery, and Product Culture In Depth
Product model first principles from TRANSFORMED by Marty Cagan. Part 2/2.
Hey, Paweł here. Welcome to a free archived edition of The Product Compass.
Every week, I share actionable tips and insights for PMs.
Here are some posts you might have missed:
Subscribe now, if you haven’t already, for the full experience:
Product Model First Principles: Product Discovery, Product Delivery, and Product Culture In Depth
As promised, today we continue the product model first principles from TRANSFORMED by Marty Cagan.
They can help you make better decisions, judge new techniques, build better products, and enjoy your job as a PM.
In the previous part, we discussed eight principles. I also shared my Q&A with Marty Cagan:
In Today’s issue, I'll analyze and share my thoughts on:
Four Product Discovery Principles
Four Product Delivery Principles
Four Product Culture Principles
1. Four Product Discovery Principles
Product Discovery is the most important area for a product manager.
In this newsletter, we’ve been tackling product discovery regularly. The best, free summary: What Is Product Discovery? Product Discovery 101
Premium subscribers can also attend my Product Discovery Masterclass, learn how to combine top product discovery techniques, and demonstrate their skills at no cost.
Let’s dive into Product Discovery principles:
Principle 9: Minimize Waste
The most important insight Marty shares is:
“The first problem in product discovery is to try to solve the problem with a minimum amount of wasted time and effort” - Marty Cagan, TRANSFORMED
To understand it better, let me quote INSPIRED:
„The first truth is that at least half of your ideas are just not going to work (…) really good teams assume that at least three quarters of the ideas won’t perform like they hope.” - Marty Cagan, INSPIRED
That’s a ton of waste!
But why exactly does it happen?
Principle 10: Assess Product Risks
I’ll quote my previous post:
I’d argue that Product Management is, at its heart, about managing risk. And for every product, there are 5 risks that can materialize:
Value. Will it create value for the customers?
Usability. Will users figure out how to use it?
Viability. Can our business support it?
Feasibility. Can it be done (technology)?
Ethics. Should we do it? Are there any ethical considerations?
An observation Marty makes in TRANSFORMED is that “ethical risk is part of business viability risk.”
I agree.
We could explore how Strategyzer recognizes only three risk categories (desirability, viability, and feasibility) and how Teresa Torres recognizes the same five while visually emphasizing three. But I wasn’t sure this would add much value.
So, instead, I reached out to Marty Cagan and got a fantastic comment:
“There is an argument for making ethics its own risk. But there's also an argument for making go-to-market its own risk (which is also part of viability, and which is also unusually important). But even a taxonomy of 4 risks can be harder to remember and keep front-of-mind, and once you get to more than 4, the real worry is that it just becomes a checklist and not a way of thinking.
I tell teams that the most important thing is to consider each of these risks. The risk taxonomy is there just to help the team remember the risks.”
- Marty Cagan, 3/21/2024
Another point worth explaining is who’s on the team responsible for what risk. As we know, the product manager is explicitly responsible for value and viability risks:
“But in the product model, the product manager is explicitly responsible for ensuring value and viability” - Marty Cagan, TRANSFORMED, Chapter 10
But does it mean that others have nothing to say here? What about ethics? Wouldn’t it be better if the engineer could refuse to implement an idea she finds unethical?
I asked those questions and loved the answer:
“There are really two different questions in here (…) The second is whether anyone on the product team should be able to raise an objection to any of the risks?
There is no question as to the second, in fact I encourage engineers to not build something if they aren't convinced of the value or any of the other risks. Just like an engineer or product manager might not consider a design very usable.”
- Marty Cagan, 3/21/2024
Keep reading with a 7-day free trial
Subscribe to The Product Compass to keep reading this post and get 7 days of free access to the full post archives.