Torres on opportunity trees
📚SOURCE
💎PERMANENT NOTES
🧵SYNTHESIS
Paraphrase, not quotation: 📕 Continuous Discovery Habits, mainly the chapters on the tree, interviewing and assumption testing.
Torres takes Cagan's idea of discovery and turns it into a routine. Her definition is strict: the team that builds the product talks to customers at least weekly, in small doses, in pursuit of one agreed outcome.
The tool that holds it together is a tree with four levels. At the root, an outcome: a measurable change the team is responsible for. Under it, opportunities: needs, pains and wishes that customers have expressed in their own stories. Under each chosen opportunity, several candidate solutions. Under each solution, the assumptions it rests on and the small tests that would check them.
The tree makes two mistakes hard to commit. You cannot attach a solution that answers no opportunity. And you cannot fall in love with one idea, because the form demands rivals beside it.
✨KEY IDEAS
An outcome is a change in what customers do that the team can influence, not a revenue figure and not a feature shipped.
Opportunities come from customers' accounts of specific past events, and are worded as their need, not our fix.
Choose one opportunity at a time and generate at least three different solutions for it.
Break each solution into the assumptions that must hold for it to work, and test the riskiest cheaply before building anything.
Write up each interview on one page, with a memorable quote, the facts, and the opportunities heard.
📝READING NOTES
Why now
📂 Carrier Scorecards discovery started on Monday. The question is whether customers can score their carriers fairly on data we already hold. I have two design partners and, for once, no date. I read the book over the first two weeks of the month to avoid running the Exceptions Inbox again with better intentions.
The tree
Outcome
└── Opportunity (a customer need, in their words)
├── Opportunity (smaller, more specific)
│ ├── Solution A ── assumptions ── tests
│ ├── Solution B ── assumptions ── tests
│ └── Solution C ── assumptions ── tests
└── Opportunity
My own description is in 🧩 Opportunity solution tree. The rules I am holding myself to:
- Nothing goes on the opportunity level unless a customer said it, about something that happened.
- An opportunity must allow more than one solution. If only one thing could answer it, it is a feature request with a paragraph in front.
- One target opportunity at a time.
Interviewing, her way
She wants stories, not opinions. Tell me about the last time a carrier let you down gets a Tuesday, a shipment and a phone call. What would you want in a scorecard gets a wish list from someone being polite. Then one page per conversation, written the same day.
After the first conversations I have a small wall of pages, and the pattern on it is not the one I walked in with. That is the method earning its keep in week one.
Where I do not follow her
The book assumes a consumer product or a large base of users one can recruit from automatically. I have two design partners, each with a handful of people who do the job. Weekly interviews would exhaust them by October. My adaptation: every fortnight with the partners, and in the weeks between, an hour with Amara's support tickets, which are customers telling stories unprompted. She would probably allow it. It is not what the book says.
- The tree is a diagram, and I know what I do with diagrams. On Wednesday I caught myself choosing colours for the branches. The tree is done when it changes what I do on Monday, not when it is tidy.
- She is light on what to do when the outcome itself is wrong. The tree hangs from it without question.
Against Cagan
📖 Cagan on product discovery says why: ideas fail, so find out cheaply. Torres says when: every week, as a habit, so that discovery is not a phase that ends when building starts. Together they are one claim, and it already has a note.
What it produced
- 💎 Discovery is cheaper than delivery so do more of it (extended today with the interview arithmetic)
- 💎 An opportunity is a customer problem and not a feature in disguise (new)
Noor told me properly today that she is going to Copenhagen. I wrote this afterwards, slowly.
Added 16 November: prototype sessions done. The tree held: every session traced back to one opportunity, and I could say which assumption each was there to test.
Rules For Scorecards
- Done: One snapshot page per interview, written the same day
- Done: Three solutions per target opportunity before discussing any
- Done: Support tickets as interviews in the off weeks
- Still open: Redraw the tree only when an opportunity changes, never to tidy it
Related notes
- 🧩 Opportunity solution tree
- 🧭 Interview snapshot
- 📂 Carrier Scorecards discovery
- 📖 Cagan on product discovery
Reading record
- Read for: work
🗣️IN SHORT
- In : Continuous Discovery Habits, the chapters on outcomes, the opportunity solution tree, interviewing and assumption testing
- Torres argues that : discovery should be a weekly habit of the building team, structured so that solutions stay tied to customer needs and to a single outcome
- by stating that : a tree of outcome, opportunities, solutions and assumption tests makes the reasoning visible, forces alternatives, and lets the riskiest assumption be tested before anything is built