Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value
by Teresa Torres
Rating: 5.0 / 5 · Read · Finished 2023-05-09
I loved it!
It’s the second book I’ve read on product management (after Escaping the Build Trap). This one is so cool! Super pragmatic. It’s defines a whole system for product discovery (figuring out what to build) which is continuous (cyclical, constantly feeding back into itself). It’s pragmatic in that it sets rules only as strictly as they need to be to be useful. For example, there’s a chapter on testing your assumptions which draws inspiration from the scientific process, but it stops short of the rigor of actual scientists. The whole philosophy is about delivering outcomes, agnostic to how they are delivered.
The process revolves around the Opportunity-Solution Tree (OST) which represents your current understanding of the problem space.
- persistent: you keep it around and fall back to other branches when one doesn’t work out
- changing: you update it as you learn more about the problem
- shared: stakeholders can always see your current understanding of the problem
- graphical: you externalize your assumptions to make them easier to think about
Tidbits:
- A “product trio” is a product manager, a designer and an engineer
- Mindsets used throughout the book: outcome over output, customer-centric, collaborative, visual, experimental, continuous
- You start with an “ill-structured problem” (infinite solution space. no right or wrong, only better and worse). “Framing” is applying structure (converting infinite solution space to finite solution space). I think it’s similar to modeling.
- interview customers weekly
- in interviews, as for (1) recent (2) specific examples. Customers are unreliable at generalizing about their own behavior
- Record opportunities, not solutions. Given a solution, ask “what would that give you?”. That’s the opportunity it addresses. There are always multiple ways to address an opportunity.
- Brainstorm individually, then share ideas, then repeat a couple times
- Testing solutions is expensive. Test assumptions instead.
- General pattern/tool used throughout the book: (1) generate a list of categories, (2) generate ideas for each category, (3) rank ideas along one or two axes, (4) identify the top couple candidates, (5) develop those candidates, (6) take what you learned and go back to the beginning
- Design experiments that can test your assumptions quickly (1-2 days) before committing to investigating an idea for thoroughly
- Design experiments that will convince your team / stakeholders
- “We can afford false negatives because ideas and opportunities are abundant”. If you generate lots of ideas, then it’s not a big deal to kill one idea and fall back to the next best one.
- Convince people by showing your work. Show them how you arrived at the conclusion and ask which part they would do differently. Be open to their ideas
Random thoughts:
- Developers could also apply this strategy to architecture design or debugging. Really, anyone could apply this strategy to any problem.
- The book completely ignores development and project management. All it’s good at is deciding what products to build. It interacts with developers through a limited API: Please build this thing. Please tell me how long it would take to build this thing. It’s up to developers to manage tech debt.