Implements Teresa Torres' continuous discovery habits for weekly customer contact, opportunity solution trees, and assumption testing. Use when building discovery processes, conducting user research, validating assumptions, or establishing product trio workflows.
90
88%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Claude uses this skill when:
The Core Principle:
"At a minimum, weekly touchpoints with customers by the team building the product, where they conduct small research activities in pursuit of a desired outcome."
The Three Pillars:
Use when: Establishing discovery processes or improving product decisions
The Team:
Why Together:
"When a designer, engineer, and PM collaborate on discovery, you get better decisions faster. Each brings a unique lens."
How:
The Structure:
Outcome (top)
↓
Opportunities (customer needs/pain points)
↓
Solutions (possible ways to address)
↓
Assumptions (what needs to be true)
↓
Experiments (how to test)Use when: Need to visualize the path from outcome to solution
Example:
Outcome: Increase retention to 80%
↓
Opportunity: Users forget to use the product
↓
Solution: Daily email reminder
↓
Assumption: Users check email daily
↓
Experiment: Survey 20 users about email habitsThe One-Pager: After each interview, create a snapshot capturing:
Why: Keeps learning accessible to the whole team
The Progression:
Story → Assumptions → Tests → EvidenceQuestion to Ask:
"What needs to be true for this solution to work?"
Test Types (by risk/cost):
Rule: Test highest-risk assumptions first with lowest-cost method
Do we have a clear outcome?
├─ No → Define outcome first
└─ Yes → Have we interviewed 6+ customers?
├─ No → Do discovery first
└─ Yes → Have we identified opportunities?
├─ No → Map opportunities
└─ Yes → Have we tested key assumptions?
├─ No → Test assumptions first
└─ Yes → Build it!What's the risk if we're wrong?
├─ Low risk → Build and ship (reversible)
└─ High risk → How much does testing cost?
├─ Low cost → Interview 5 users
├─ Medium cost → Prototype test
└─ High cost → Still cheaper than building wrong thing# Weekly Discovery Plan - Week of [Date]
## Outcome We're Pursuing
[e.g., Increase activation rate to 50%]
## This Week's Focus
**Opportunity:** [Which pain point are we exploring?]
**Solution:** [Which solution are we considering?]
**Key Assumption:** [What needs to be true?]
## Discovery Activities (Minimum 1 per week)
### Monday-Wednesday: Research
- [ ] Interview 1: [Participant profile] - [PM/Designer/Engineer attending]
- [ ] Interview 2: [Participant profile] - [PM/Designer/Engineer attending]
- [ ] Interview 3: [Participant profile] - [PM/Designer/Engineer attending]
### Thursday: Synthesis
- [ ] Product trio synthesis session (30 min)
- [ ] Create/update interview snapshots
- [ ] Update opportunity solution tree
- [ ] Identify new assumptions to test
### Friday: Planning
- [ ] Review evidence collected
- [ ] Decide: build, test more, or pivot?
- [ ] Plan next week's discovery activities
## Interview Snapshots
[Link to snapshots folder]
## Opportunity Solution Tree
[Link to latest tree]# Interview Snapshot - [Date]
## Participant
- **Name/ID:** [Anonymized if needed]
- **Role:** [Job title/persona]
- **Context:** [Relevant background]
## Interview Focus
[What we were trying to learn]
## Key Insights
1. [First major insight]
2. [Second major insight]
3. [Third major insight]
## Opportunities Discovered
- 📍 [Pain point or unmet need #1]
- 📍 [Pain point or unmet need #2]
- 📍 [Pain point or unmet need #3]
## Memorable Quotes
> "[Exact customer words that capture key point]"
> "[Another powerful quote]"
## Updated Assumptions
- ✅ Validated: [What we confirmed]
- ❌ Invalidated: [What we disproved]
- ❓ New: [New assumptions to test]
## Next Steps
- [ ] [Specific action based on learning]
- [ ] [Another action]
## Attending
- [PM name]
- [Designer name]
- [Engineer name]# Opportunity Solution Tree - [Product/Feature Name]
## Outcome
🎯 **[Business outcome we're driving]**
[Specific, measurable, time-bound]
---
## Opportunities (Customer Needs/Pain Points)
### Opportunity 1: [Customer problem]
**Evidence:** [3-5 customer interviews, usage data, etc.]
**Impact:** [How big is this problem?]
#### Solutions Being Considered:
1. **[Solution A]**
- Assumptions:
- [ ] Assumption 1
- [ ] Assumption 2
- Tests: [How we'll validate]
- Status: [Testing/Building/Shipped]
2. **[Solution B]**
- Assumptions:
- [ ] Assumption 1
- [ ] Assumption 2
- Tests: [How we'll validate]
- Status: [Testing/Building/Shipped]
### Opportunity 2: [Another customer problem]
**Evidence:** [3-5 customer interviews, usage data, etc.]
**Impact:** [How big is this problem?]
[Continue for each opportunity...]
---
## Decision Log
- **[Date]:** Chose Solution A for Opportunity 1 because [evidence]
- **[Date]:** Decided to test Assumption X before building
- **[Date]:** Pivoted from Solution B to Solution C based on [learning]# Assumption Test Plan - [Feature/Solution Name]
## Solution Statement
[Brief description of what we're considering building]
## Key Assumptions
### Assumption 1: [High Risk]
**Statement:** [What needs to be true]
**If wrong:** [What's the impact?]
**Confidence:** [Low/Medium/High]
**Test Method:** [Interview/Survey/Prototype/etc.]
**Success Criteria:** [What would validate this?]
**Timeline:** [When we'll test]
**Owner:** [Who's running the test]
---
### Assumption 2: [Medium Risk]
**Statement:** [What needs to be true]
**If wrong:** [What's the impact?]
**Confidence:** [Low/Medium/High]
**Test Method:** [Interview/Survey/Prototype/etc.]
**Success Criteria:** [What would validate this?]
**Timeline:** [When we'll test]
**Owner:** [Who's running the test]
---
## Test Results
### Assumption 1 Results
**Date Tested:** [Date]
**Method Used:** [What we did]
**Sample Size:** [How many participants]
**Findings:**
- [Key finding 1]
- [Key finding 2]
- [Key finding 3]
**Decision:** ✅ Validated / ❌ Invalidated / ❓ Needs more testing
**Next Steps:** [What we'll do based on results]
---
### Assumption 2 Results
[Same structure as above]Every Week Minimum:
Every Month:
Good Discovery Practice:
Signs of Insufficient Discovery:
Before Creating:
When Building Tree:
Using the Tree:
Test in This Order:
Use Cheapest Test First:
Interview < Survey < Prototype < Concierge < BuildOutcome: Increase music discovery engagement
Opportunity: Users don't know what to listen to
Key Learning: They tested the algorithm assumption before building fancy UX
Outcome: Reduce time to content consumption
Opportunity: Users forget what they were watching
Key Learning: Small test before full build saved months of work
Problem: Doing research but not changing decisions Solution: Explicitly decide what you'll do if assumptions are wrong
Problem: PM does research, then "throws it over the wall" Solution: Product trio interviews together
Problem: Spreading resources too thin Solution: Test assumptions first, build one at a time
Problem: Building wrong thing is slowest path Solution: Small tests are faster than big rebuilds
Problem: Missing problems and churn reasons Solution: Interview across the spectrum (new, power, churned users)
Teresa Torres on Weekly Contact:
"If you're not talking to customers every week, you're not doing continuous discovery."
On Product Trios:
"The best product decisions come from diverse perspectives. A PM, designer, and engineer will see different things in the same customer interview."
On Opportunity Solution Trees:
"The tree makes your thinking visible. It shows how you got from an outcome to a solution, which builds stakeholder trust."
On Assumption Testing:
"Don't ask customers what to build. Test assumptions about what will work."
On Discovery vs Delivery:
"Discovery and delivery should happen continuously. Discovery doesn't end when you start building."
Use together with:
Comes before:
Comes after:
Remember: Continuous discovery isn't a phase. It's a habit. The product trio that talks to customers weekly makes better product decisions.
Guest: Teresa Torres
Book: Continuous Discovery Habits (2021)
Website: producttalk.org
Known for: Opportunity Solution Trees, Product Trios, Weekly Touchpoints
53530ef
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.