Review
I first read this in March 2022, about six weeks into a new role where discovery had been largely improvised for years. The timing was fortunate.
What separates this book from most product books is that it gives you a methodology, not a philosophy. The opportunity solution tree is the clearest example: a visual map that connects the outcome you're chasing to the opportunities you're exploring and the solutions you're testing. When you look at it and don't know your next step, that uncertainty is useful information. It tells you what question to ask next. I hadn't seen that framing anywhere before this book.
The argument for weekly customer interviews landed differently than I expected. Torres isn't making the case that talking to customers is important. That case has been made. She is arguing that weekly, short, structured conversations tied to a specific opportunity produce a different kind of insight than quarterly research sprints. One 30-minute conversation per week per product trio is enough to keep your opportunity map current. You're always asking about the thing you're actually working on, not hoping the research from three months ago still applies.
The sections on assumption testing and stakeholder communication alone would justify reading it. Read it in full.
Key Takeaways
The parts worth keeping:
Outcomes, not outputs
- Agile fixed the delivery problem. It didn't fix the problem of building the wrong thing. Teams that ship fast without validating opportunities are optimizing the wrong variable.
- Three levels to keep distinct: business outcomes are lagging indicators that drive the business; product outcomes are the leading indicators teams can actually move; traction metrics track feature usage and assume you already know the right solution. Assign teams product outcomes, not business outcomes or traction metrics.
| Level | What it measures | Example |
|---|---|---|
| Business outcome | What drives the business | 90-day retention |
| Product outcome | How the product drives business value | Dogs who like the food after week 2 |
| Traction metric | Usage of a specific feature | Owners who use the transition calendar |
- Outcome-setting is a negotiation, not a directive. The product leader brings business context; the team brings customer and technology knowledge. Solutions shouldn't come up in this conversation.
The opportunity solution tree
- The tree is a visual map of the paths you might take to reach a desired outcome: business outcome at the root, customer opportunities at the next level, solutions below that. It keeps strategy visible and prevents you from optimizing in the solution space before you have picked the right opportunity.
- Frame opportunities from the customer side. Opportunities are pain points, desires, and needs, not business requirements. If there's more than one way to solve it, it's an opportunity. If it looks like a solution, it belongs lower in the tree.
- Prioritize opportunities top-down: compare siblings at the highest level first, eliminate the losers, then move down one level. Four factors to weigh: opportunity size, market position, company fit, and the gap between how important this is to customers and how satisfied they currently are.
- Product strategy lives in the opportunity space, not the solution space. Jumping to solutions before picking a target opportunity means making bets without understanding the terrain.
Interview as instrument, not event
- Ask about specific past behavior, not general preferences. "Tell me about the last time you did X" produces more reliable data than "What do you normally do when X?" People rationalize after the fact; stories anchor them to what actually happened.
- Use temporal prompts to keep participants concrete: "Where were you? What happened first? What happened next?" If you ask a short question, you get a short answer.
- Synthesize after each interview with a one-page snapshot: name, customer segment, key insights, opportunities surfaced, one or two quotes. Don't send recordings or long notes. People won't read them.
- Get the full product trio into interviews. Each person hears different things. Having one person act as the voice of the customer removes the whole point of having three perspectives in the room.
Assumption mapping
- Test assumptions before testing ideas. It's faster, and it forces you to name what you actually believe will be true. Most teams can't do this, which is the real reason their experiments are inconclusive.
- Work with three solution ideas simultaneously, not one. Testing a single idea creates attachment. Testing three keeps you honest about which idea is actually best.
- Five assumption categories to map before committing to any solution:
| Category | The question |
|---|---|
| Desirability | Does anyone want this? Will they get value from it? |
| Viability | Should we build it? Does it generate more value than it costs to build and maintain? |
| Feasibility | Can we build it? Technical, legal, regulatory constraints. |
| Usability | Will they find it, understand it, and be able to use it? |
| Ethical | What data are we collecting, how are we using it, and would our customers be comfortable if they knew? |
- Run a pre-mortem: assume it's six months out and you launched and it failed. Ask what went wrong as if the failure is certain. This surfaces assumptions you would otherwise not articulate.
- Prioritize which assumptions to test on a 2x2: how much you already know versus how important the assumption is. Test the ones you know least about that would break everything if wrong.
Show your work
- If you present conclusions to stakeholders without showing your reasoning, they will override you with their own solution ideas. Walk through the tree instead: what outcome you're chasing, how you picked the target opportunity, what customers told you, what you're testing now.
- Stakeholders who follow the journey step by step are far more likely to trust team decisions than those who only see a finished recommendation. Visible reasoning earns more autonomy than presented conclusions.