opportunity-solution-tree
Use when you need to ensure every feature in the backlog connects to a measurable business outcome — applies Teresa Torres' OST framework to map outcomes → opportunities → solutions → experiments.
Best use case
opportunity-solution-tree is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when you need to ensure every feature in the backlog connects to a measurable business outcome — applies Teresa Torres' OST framework to map outcomes → opportunities → solutions → experiments.
Teams using opportunity-solution-tree should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/opportunity-solution-tree/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How opportunity-solution-tree Compares
| Feature / Agent | opportunity-solution-tree | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when you need to ensure every feature in the backlog connects to a measurable business outcome — applies Teresa Torres' OST framework to map outcomes → opportunities → solutions → experiments.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Opportunity Solution Tree (OST)
Teresa Torres' **Opportunity Solution Tree** prevents building features that don't
matter. It ensures every solution you build is connected to a real user pain
and a business outcome you care about.
## The Framework
```text
Desired Outcome
└── Opportunity 1 (user pain / unmet need)
│ ├── Solution A
│ │ ├── Experiment 1
│ │ └── Experiment 2
│ └── Solution B
└── Opportunity 2
└── Solution C
```
**Outcome**: A measurable business goal (OKR-level: "Increase trial-to-paid conversion by 15%")
**Opportunity**: A user pain, unmet need, or desire (discovered through research)
**Solution**: A product change that might address the opportunity
**Experiment**: The smallest thing you can build to test if the solution works
## Workflow
### Step 1: Define the Desired Outcome
```text
> I'm building the OST for: [product/feature area]
>
> Help me define 1 crisp desired outcome. It should be:
> - Measurable (has a metric)
> - Achievable within the quarter
> - Aligned with business goals
>
> Context: Our goal is [business context]. Key metric: [current baseline].
```
### Step 2: Map the Opportunity Space
```text
> Now let's map the opportunity space for this outcome.
>
> Based on [user research / support tickets / interview data / NPS feedback]:
> > [paste data here]
>
> Identify the top 5-7 user opportunities (pains, needs, desires) that, if addressed,
> would most directly improve [outcome metric].
>
> Format as a prioritized list with a one-sentence "when I [situation], I struggle to [pain]" statement for each.
```
### Step 3: Generate Solutions
For each top opportunity:
```text
> For the opportunity: "[opportunity statement]"
>
> Generate 5-7 possible solutions. Include:
> - Conventional solutions (what everyone would build)
> - Lateral solutions (unexpected approaches)
> - Low-tech or process solutions (not just feature builds)
>
> For each, estimate: effort (S/M/L), confidence (Low/Med/High), impact potential (Low/Med/High)
```
### Step 4: Design Experiments
For your top-priority solution:
```text
> For solution: "[solution name]"
>
> Design 3 experiments to test the core assumption, ordered from least to most expensive:
> 1. A concierge experiment (manual, no code)
> 2. A fake door / prototype test
> 3. An MVP build
>
> For each experiment, define:
> - The hypothesis: "We believe [solution] will [expected outcome] because [reason]"
> - The success metric
> - The time box
```
### Step 5: Build the Tree Visualization
```text
> Generate a Markdown-formatted OST for:
>
> Outcome: [outcome]
> Opportunities: [list]
> Solutions per opportunity: [list]
> Experiments for priority solution: [list]
>
> Use nested Markdown lists with clear labels for each level.
> Add a "Current Focus" indicator on the solution we're pursuing.
```
## SQL Tracking
Use the session database to track OST items:
```sql
CREATE TABLE ost_items (
id TEXT PRIMARY KEY,
type TEXT, -- outcome | opportunity | solution | experiment
parent_id TEXT,
title TEXT,
status TEXT DEFAULT 'active',
metric TEXT,
notes TEXT
);
INSERT INTO ost_items VALUES
('O1', 'outcome', NULL, 'Increase trial-to-paid conversion 15%', 'active', 'trial_conversion_rate', ''),
('OP1', 'opportunity', 'O1', 'Onboarding takes too long to first value', 'active', NULL, ''),
('S1', 'solution', 'OP1', 'Progressive disclosure of features', 'active', NULL, ''),
('E1', 'experiment', 'S1', 'Show only 3 steps to first task', 'in_progress', 'time_to_first_task', '');
```
## Example: SaaS Conversion OST
```text
Outcome: Increase trial-to-paid conversion rate from 12% to 18%
Opportunity 1: Users don't reach the "aha moment" before trial ends
Solution A: Personalized onboarding based on role
Experiment 1: Wizard with role selection (concierge test, 1 week)
Experiment 2: Role-based dashboard (2-week MVP)
Solution B: Proactive success manager outreach at day 3
Opportunity 2: Users don't trust us with their real data during trial
Solution A: Pre-loaded demo data matching user's industry
Solution B: "Import 10 rows free" limited trial import
Opportunity 3: Trial users don't share product with team
Solution A: Collaborative invitation flow mid-trial
```
## Tips
- **One outcome at a time**: A single team can only optimize one metric at a time. Multiple outcomes = diffused focus.
- **Separate opportunity discovery from solution generation**: Don't jump to solutions before mapping pains.
- **Experiments > builds**: The goal is to learn cheaply. Most solutions shouldn't become builds.
- **Continuous tree**: OST is a living document. Update it weekly as you learn.
- **Start with existing data**: Support tickets, NPS verbatims, and session recordings are free opportunity maps.Related Skills
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.