--- name: opportunity_solution_trees description: Build and run Teresa Torres's Opportunity Solution Tree for continuous product discovery: anchor a desired outcome, map customer opportunities from story-based interviews, generate competing solutions, and sequence small assumption tests. Triggers on product discovery work, deciding what to build, weekly discovery cadence setup, assumption testing, and roadmaps with no customer evidence. --- # Opportunity Solution Trees ## Purpose Turn "what should we build?" into a visible, testable map. One desired outcome sits at the root. Under it branch opportunities (unmet needs, pains, desires heard from customers). Under each opportunity hang competing solutions. Under each solution hang assumption tests, the smallest experiments that resolve the riskiest beliefs before you commit to building. From Teresa Torres's *Continuous Discovery Habits* (Product Talk, 2021). The tree's one rule: **no solution may hang from anything but an opportunity.** The moment you cannot name the customer experience a solution serves, the tree has exposed your real problem. ## Workflow ### 1. Root it in one outcome Pick the behavior you are responsible for moving, phrased as customer behavior change, not output. "Increase new readers" is an outcome. "Ship a share button" is not. One tree, one outcome. ### 2. Collect stories, not opinions (weekly) Interview at least one customer a week, run by the people building the product. The interview form: "Tell me about the last time you [relevant behavior]." Never ask for opinions, predictions, or generalizations ("would you use this?"). Details in `references/interview-guide.md`. After each interview, write a one-page snapshot: who, context, the story, opportunities surfaced, verbatim quotes. Update the opportunity space every 3-4 interviews. Opportunities get smaller as you go down the tree: broad ("can't evaluate what's worth my time") narrows to specific ("can't tell if this article matches my interests before opening it"). ### 3. Map opportunities, then widen Place each opportunity in the customer's words, as something they experience, not something you build. Test every statement: "Is this something the customer experiences, or something we build?" If it names a feature ("users need a dashboard"), it is a solution wearing an opportunity costume. Strip it back to the experience: "I can't see my progress at a glance." Opportunities above you have no solutions under are dead ends. Opportunities with exactly one solution are the one-idea funnel; force at least three competing solutions before you commit to any of them. ### 4. Surface the assumptions under each solution For every solution, ask what must be true for it to work. Assumptions fall in five categories: - **Desirability:** do customers want this, and will they do what it takes to get value? - **Viability:** is it good for our business? - **Feasibility:** can we build it? (includes compliance, security, mission fit, not just tech) - **Usability:** can customers find it, understand it, use it? - **Ethical:** could this cause harm, and whose data does it touch? ### 5. Sequence tests, riskiest first One assumption per test. If a test can fail in two ways, you will not know which broke. Pick the assumption with the highest importance and the weakest evidence and test that first. Do not test the whole idea; testing the whole idea is what building is. Catalog of test formats in `references/assumption-tests.md`. The tree is living. Each week's interviews and test results update it: evolve a solution, pick a different opportunity, or reconsider the outcome. Never discard the thinking you have mapped; a killed branch is cheaper than a shipped one. ### 6. Use the CLI to keep it honest `bin/ost.py` reads a tree file and enforces the structure: ``` ost.py render tree.yaml # ascii tree, readable by humans and agents ost.py validate tree.yaml # structural checks: one-idea funnels, orphan solutions, invalid assumption types ost.py next tree.yaml # riskiest untested assumption across the tree: what to test this week ``` Tree schema and a worked example live in `assets/example-tree.yaml`. ## Output Contract A completed pass produces: - `tree.yaml`: outcome, opportunities with interview evidence, solutions, assumptions with types and evidence levels, and one-assumption tests. - `ost.py validate tree.yaml` exits 0 with no ERROR lines. - A short sequencing memo: this week's target opportunity, the assumption under test, the test format, and what evidence would kill the solution. ## Operating Rules 1. No invented evidence. Every opportunity links to a real story source; if you have no interviews yet, label the tree DRAFT and run the interviews before widening. 2. Never quantify with fake precision. Sequence by risk (importance x evidence gap), not by a scoring formula. Messy, subjective judgment is the input, the tree is just how you keep it visible. 3. Discovery runs in parallel with delivery, never as a phase. A tree that only gets updated during "research sprints" is decoration. 4. Interviewers never read solutions to participants. The moment you describe your idea in an interview, you have contaminated the data. 5. Ethics is a category, not a filter pass. Ask it on every solution, including the ones everyone already likes.