# Opportunity Solution Tree: [Outcome]

> An opportunity solution tree is a visual map for continuous product discovery: one desired outcome at the root,
> the customer opportunities (needs, pain points and desires) that could drive it, candidate solutions for a chosen
> target opportunity, and the assumption tests that show which solution is worth building. The concept was
> introduced by Teresa Torres and is described in *Continuous Discovery Habits* (Product Talk, 2021). This template
> uses the concept only, in original words. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Fill top-down: outcome (section 1), then opportunities from research (section 2), then pick one target
  opportunity (section 3), then at least three solutions (section 4), then the assumptions behind the favourite
  solutions and the tests for them (section 5).
- Opportunities come from customers (interviews, observation, data), never from the team's solution ideas. If an
  "opportunity" can only be solved one way, it is a solution in disguise.
- Update the tree every week while discovery runs; it is a living map, not a one-off plan.
- The worked example continues the fictional company Tallow Notes from product/product-vision-strategy (bet B1) and
  product/north-star-metric (input I1).
-->

## Document control

| Field | Value |
|---|---|
| Document ID | [OST-TEAM-NN] |
| Product trio | [@product-manager, @designer, @engineer] |
| Linked strategy or bet | [Strategy ID and bet] *Example:* PVS-TALLOW-01, bet B1 |
| Status | [Exploring / Testing / Building / Closed] |
| Last updated | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@owner] | Tree started from interview synthesis |
| [0.2] | YYYY-MM-DD | [@owner] | [Target opportunity chosen, tests added] |

## 1. Desired outcome

<!-- Guidance: Choose a product outcome: a measure of customer behaviour in the product that the team can influence, rather than a business outcome such as revenue (too far away) or a feature adoption count (too narrow). One outcome per tree. -->

| Field | Value |
|---|---|
| Outcome | [Metric, baseline, target, date] |
| Why this outcome | [Link to north star input or OKR] |
| Leading signal reviewed weekly | [Signal] |
| *Example:* Outcome | Share of new workspaces activated (second member edits a shared note within 7 days) rises from 31% to 40% by 2027-06-30 |
| *Example:* Why | Drives input I1 of the north star (weekly collaborating workspaces) and bet B1 |
| *Example:* Leading signal | Share of new workspaces that send at least one invitation on day 1 |

## 2. Opportunity space

<!-- Guidance: List customer needs, pain points and desires heard in research, in the customer's words where possible. Group them under parent opportunities, and keep the evidence link for each. Pitfall: listing features ("add templates") instead of needs ("I don't know what to write first"). -->

| ID | Opportunity (customer need, pain or desire) | Parent | Evidence | Customers affected | Size signal |
|---|---|---|---|---|---|
| OPP-1 | [Need] | none | [Research IDs] | [Segment] | [How many, how often] |
| OPP-1 *(Example)* | "I don't want to invite my team to an empty space" | none | RES-031 (11 of 24 interviews) | Team leads setting up | High |
| OPP-1.1 *(Example)* | "I don't know what our team should write down first" | OPP-1 | RES-031, RES-034 | Team leads | High |
| OPP-1.2 *(Example)* | "My colleagues won't learn yet another tool" | OPP-1 | RES-031 (7 of 24) | Team leads | Medium |
| OPP-2 *(Example)* | "When someone joins, they don't see what changed or what to read" | none | RES-031 (6 of 24) | Invited members | Medium |
| OPP-3 *(Example)* | "I can't tell whether anyone read what I wrote" | none | RES-034 open answers | Writers | Low |

## 3. Target opportunity

<!-- Guidance: Compare the sibling opportunities on size, market factors, company factors and customer importance, then pick one. Record why, so the choice can be revisited. -->

**Target opportunity:** [ID and text]

**Why this one:** [Reasoning, with evidence]

*Example:* OPP-1.1 "I don't know what our team should write down first". It appeared in the most interviews, it
blocks the moment of inviting colleagues (the outcome), and the team can address it without new infrastructure.
OPP-2 is kept for the next cycle.

## 4. Solutions

<!-- Guidance: Generate at least three distinct solutions for the target opportunity before picking, so you compare options instead of confirming one idea. Solutions can be small. -->

| ID | Solution | Opportunity | Effort (T-shirt) | Notes |
|---|---|---|---|---|
| SOL-1 | [Idea] | [OPP ID] | [S / M / L] | [Notes] |
| SOL-1 *(Example)* | Starter spaces by team type (agency, studio, product team) with three pinned notes to complete together | OPP-1.1 | M | Candidate for bet B1 |
| SOL-2 *(Example)* | A guided "first week" checklist inside an empty workspace | OPP-1.1 | S | |
| SOL-3 *(Example)* | Import the last 30 days of a chat channel as a draft note | OPP-1.1 | L | Needs integrations |

```mermaid
flowchart TD
    O["Outcome: activation 31% to 40% by 2027-06-30"] --> P1["OPP-1 Empty space blocks inviting"]
    O --> P2["OPP-2 New members do not know what to read"]
    O --> P3["OPP-3 Writers cannot see if notes are read"]
    P1 --> P11["OPP-1.1 Do not know what to write first"]
    P1 --> P12["OPP-1.2 Colleagues resist a new tool"]
    P11 --> S1["SOL-1 Starter spaces by team type"]
    P11 --> S2["SOL-2 First-week checklist"]
    P11 --> S3["SOL-3 Import chat channel as draft"]
    S1 --> T1["AT-01 Fake-door test of starter choice"]
    S1 --> T2["AT-02 Prototype test with 6 team leads"]
    S2 --> T3["AT-03 One-question survey in empty workspace"]
```

## 5. Assumptions and assumption tests

<!-- Guidance: For the two or three most promising solutions, list the assumptions that must be true for them to work, by type: desirability (do they want it), viability (does it work for the business), feasibility (can we build it), usability (can they use it) and ethical (could it cause harm). Test the riskiest, least-evidenced assumptions first with the smallest test that could change your mind. Set the success threshold before running the test. -->

| Test ID | Solution | Assumption | Type | Test method | Success threshold (set before) | Result | Decision |
|---|---|---|---|---|---|---|---|
| AT-01 | [SOL ID] | [Assumption] | [Desirability / Viability / Feasibility / Usability / Ethical] | [Method] | [Threshold] | [Result] | [Continue / Change / Drop] |
| AT-01 *(Example)* | SOL-1 | Team leads will pick a starter space rather than start blank | Desirability | Fake-door choice on the new-workspace screen for 1 week | At least 40% pick a starter | 52% of 1,310 picked a starter (681) | Continue |
| AT-02 *(Example)* | SOL-1 | Team leads can complete a pinned note in under 5 minutes | Usability | Moderated prototype test with 6 team leads | 5 of 6 succeed | 4 of 6 succeeded; two missed the edit button | Change: make notes editable in place |
| AT-03 *(Example)* | SOL-2 | A checklist is seen as helpful, not as homework | Desirability | One-question in-product survey, 200 responses | At least 60% "helpful" | Not run yet | Pending |
| AT-04 *(Example)* | SOL-1 | Starter content does not mislead regulated teams (for example legal or health studios) | Ethical | Content review by two team leads in regulated fields | No misleading example notes | Not run yet | Pending |

## 6. Decisions and next steps

<!-- Guidance: Record what the team decided after the latest tests, so stakeholders can follow progress without reading the whole tree. Link the backlog items created. -->

| Date | Decision | Evidence | Backlog items |
|---|---|---|---|
| YYYY-MM-DD | [Decision] | [Test IDs] | [PBI IDs] |
| *Example:* 2026-11-20 | Build SOL-1 as a minimal version (three team types), keep SOL-2 as a fallback | AT-01, AT-02 | PBI-101, PBI-102 |

## Related templates and references

- product/product-vision-strategy and product/north-star-metric for the outcome's context
- design/ux-research-plan, startup/customer-discovery, product/persona for research input
- product/ab-test-plan to measure the shipped solution against the outcome
- product/product-backlog for the items created from validated solutions
- Torres, T. (2021). *Continuous Discovery Habits*. Product Talk LLC. ISBN 9781736633304.
- Torres, T. "Opportunity Solution Trees" (article): https://www.producttalk.org/opportunity-solution-trees/

## Standard and licence note

Structure aligned with the opportunity solution tree concept described by Teresa Torres. The concept is cited by name
only; no text, diagrams or examples are copied from the book or articles, and all wording and the Tallow Notes
example are original. The book is a paid publication. Official text: Product Talk, purchase or licensed access:
https://www.producttalk.org/continuous-discovery-habits/. Template licence: MIT.