Use this skill when applying Jobs-to-be-Done, building opportunity solution trees, mapping assumptions, or validating product ideas. Triggers on product discovery, JTBD, jobs-to-be-done, opportunity solution trees, assumption mapping, experiment design, prototype testing, and any task requiring product discovery methodology.
Use this skill when applying Jobs-to-be-Done, building opportunity solution trees, mapping assumptions, or validating product ideas. Triggers on product discovery, JTBD, jobs-to-be-done, opportunity solution trees, assumption mapping, experiment design, prototype testing, and any task requiring product discovery methodology.
Discover continuously, not in phases - Discovery is not a gate before
delivery. It runs in parallel with shipping. Every sprint produces both
validated learning and working software. "Done with discovery" is a warning sign.
Outcomes over outputs - The goal is a measurable change in customer behavior,
not a feature shipped. Define success as a behavioral outcome first; the solution
is just a hypothesis about how to reach it.
Test assumptions, not ideas - Every solution idea rests on a stack of
assumptions. Surface the riskiest ones first and test those - not the idea in its
entirety. This collapses validation time by 10x.
Smallest experiment possible - Always ask: "What is the cheapest, fastest
way to learn whether this assumption is true?" A 5-minute interview, a smoke test,
or a paper prototype can invalidate months of engineering work.
Dual-track: discovery and delivery in parallel - One track discovers the next
problem worth solving; the other delivers on already-validated solutions. Teams
that separate these into sequential phases go dark on learning for months at a time.
Core concepts
JTBD Framework
Jobs-to-be-Done treats customer behavior as hiring a product to do a job. The
canonical JTBD statement is:
"When [situation], I want to [motivation], so I can [expected outcome]."
Jobs have three layers:
Functional job - The practical task (file my taxes quickly)
Emotional job - How the customer wants to feel (confident I won't get audited)
Social job - How they want to be perceived (look responsible to my partner)
Strong solutions address all three layers. Most competitors only address the
functional job, leaving emotional and social value uncaptured.
Interview for jobs by asking about the last time the customer did the relevant
behavior - not hypotheticals. "Tell me about the last time you..." surfaces actual
pull, struggle, and workaround data.
Opportunity Solution Trees
The opportunity solution tree (OST) - developed by Teresa Torres - is a visual tool
that maps the path from a desired outcome to the experiments that test candidate
solutions.
The root is always an outcome (metric), never a solution
Opportunities are discovered from customers - not invented in the office
Each solution sits below a single opportunity - never jump to solution without an opportunity
Every solution has at least one assumption being actively tested
Assumption Types
Every product bet rests on four categories of assumptions:
Type
Question it answers
Example
Desirability
Do customers want this?
"Users want to share playlists with non-subscribers"
Viability
Can we make money from it?
"Enterprise customers will pay $50/seat for SSO"
Feasibility
Can we build it?
"We can infer intent from existing event data"
Usability
Can customers use it without friction?
"Users can complete onboarding without a tooltip"
Prioritize assumptions by: risk x proximity to a decision. Test the assumption
that, if wrong, would kill the bet - before testing assumptions about optimization.
Experiment Hierarchy
From lowest to highest fidelity and cost:
Assumption audit - List and stack-rank assumptions; no customer contact yet
Secondary research - Existing data, competitor analysis, academic studies
Customer interview - 30-60 min; 5-8 participants for a theme to emerge
Survey - Quantifies frequency of a qualitatively discovered pattern
Smoke test / landing page - Measures real intent without building the feature
Wizard of Oz - Manual fulfillment behind a product interface
Prototype test - Simulates the experience at chosen fidelity (paper, lo-fi, hi-fi)
Concierge MVP - Deliver the value manually; learn the job deeply
Technical spike - Validate feasibility assumption with a time-boxed build
A/B test / live experiment - Measures actual behavior change in production
See references/experiment-playbook.md for templates by assumption type.
Common tasks
Conduct JTBD interviews
Framework (45-60 min):
Recruitment - Screen for people who have recently done the behavior you're
studying. Recent = within 90 days. Avoid future-intent screening questions.
Timeline reconstruction (20 min) - "Walk me through everything that happened
from the moment you first realized you needed [solution category] to the moment
you made a decision." Map: first thought, passive looking, active looking, deciding.
Dig into the struggle (15 min) - "What had you tried before? What was
unsatisfying? What almost made you not switch?"
Outcomes and anxieties (10 min) - "What were you hoping would be different?
What were you worried might not work?"
Wrap (5 min) - "If you could change one thing about [product], what would
it be?" Use sparingly - this is ideation, not discovery.
Output: Job stories, struggle patterns, and switch triggers. Theme across 5+
interviews before drawing conclusions.
Build an opportunity solution tree
Start with the outcome - Name the metric the product trio owns this quarter,
e.g., "Increase week-2 retention from 42% to 55%."
Generate opportunities from interview data - Each opportunity is an unmet need,
pain, or desire expressed by a real customer. Do not invent opportunities in workshops.
Cluster and name - Group related struggles. Name them as customer problems
("I lose context when switching devices"), not solutions ("add cross-device sync").
Select the focus opportunity - Use impact/confidence/ease to compare. Pick one.
Brainstorm solutions - Generate 3+ candidate solutions per opportunity.
Quantity over quality at this stage. Include unconventional ideas.
Map assumptions per solution - For each candidate, list what must be true for
it to work. Sort by type (desirability/viability/feasibility/usability).
Design one experiment per risky assumption - Smallest test that could change
your mind. Assign owner and timeline.
Map and prioritize assumptions
Use a 2x2 matrix: Certainty (known vs. unknown) x Risk (low vs. high).
High risk, low certainty - Test immediately. These are bet-killers.
High risk, high certainty - Monitor. You believe these but should revisit if evidence shifts.
Low risk, low certainty - Research when convenient. Won't kill the bet.
Low risk, high certainty - Ignore for now.
For each risky assumption, write a falsifiable statement: "We believe X. We will
know this is true when we see Y. We will know it is false when we see Z."
Design validation experiments
Match the experiment type to the assumption category:
Assumption type
Preferred experiment
Signal to look for
Desirability
Customer interview, smoke test
Pull signals + click-through rate
Viability
Pricing interview, willingness-to-pay study
20%+ "definitely would pay" at target price
Feasibility
Technical spike, data audit
Can be built within X sprints
Usability
Usability test (think-aloud)
Task completion rate, errors, time-on-task
Every experiment needs: hypothesis, method, sample size, success criterion,
and a kill threshold - the result that would lead you to abandon the bet.
See references/experiment-playbook.md for detailed templates.
Run prototype tests
Choose fidelity based on what you're testing:
Fidelity
Best for
Tools
Paper / sketch
Flow and information architecture
Pen, Balsamiq
Lo-fi wireframe
Navigation and content hierarchy
Figma (no styling)
Hi-fi mockup
Visual design and emotional response
Figma, Framer
Coded prototype
Interaction quality, performance perception
Storybook, CodeSandbox
Production feature
Behavior change, retention, conversion
Feature flag in prod
Think-aloud protocol: Brief the participant ("we're testing the design, not you"),
ask them to narrate thoughts as they navigate, do not hint or help, note confusion and
errors, debrief after each task. Five participants reveal ~85% of usability issues.
Observation - What one customer said or did (raw data)
Pattern - What appeared across multiple customers (theme)
Insight - Why this pattern exists (interpretation)
Implication - What it means for the product (decision input)
Avoid jumping from observation to implication. The missing middle is where discovery
adds value over anecdote.
Affinity mapping: Write each observation on its own sticky. Group silently. Name
groups as customer problems, not solutions. Rank by frequency and intensity of pain.
Create a discovery cadence for the team
A sustainable cadence for a three-person product trio (PM, designer, engineer):
Cadence
Activity
Time
Weekly
2-3 customer interviews or usability sessions
2-3 hrs
Weekly
Assumption review: what did we learn, what changed?
30 min
Bi-weekly
OST review: update tree with new opportunities and learnings
1 hr
Monthly
Opportunity prioritization: re-rank based on new evidence
1 hr
Quarterly
Outcome review: did we move the metric? What next?
2 hrs
Talking to 2-3 customers per week compounding over a year creates an insurmountable
understanding advantage over teams that research in batches.
Anti-patterns
Anti-pattern
Why it's harmful
What to do instead
Big-bang discovery
6-week research phase before a project; team goes dark on learning during delivery
Embed 2-3 interviews per week alongside shipping; discovery never stops
Solution-first OST
Listing features at the root of the tree instead of an outcome
Always start with a measurable outcome metric; solutions are hypotheses
Validation theater
Running research to confirm a decision already made; cherry-picking supporting quotes
Write a kill threshold before the study: the result that would change your mind
Over-fitting to one customer
Pivoting strategy based on feedback from a single vocal customer
Require a pattern across 5+ independent sources before changing direction
Premature high-fidelity
Pixel-perfect prototypes before validating the core job
Match fidelity to the assumption; paper prototypes can kill 80% of bad ideas cheaply
Skipping feasibility
Testing only desirability; engineering discovers a blocker in sprint 3
Include an engineer in discovery; run a technical spike for any novel feasibility assumption
Gotchas
Recruiting interviewees through your own app produces selection bias - Users who respond to an in-app recruitment banner are your most engaged advocates. They will tell you the product is great and suggest incremental improvements. To discover why users churn or never activate, you must recruit from people who did not engage - churned users, trial non-converters, and target-persona non-users. Use external recruitment panels for discovery that needs unbiased signal.
Opportunity solution trees built in workshops produce solutions disguised as opportunities - When teams generate the OST collaboratively in a room, "opportunities" are often features rephrased as problems ("users want a better export experience" is a solution frame, not an opportunity). Real opportunities come from verbatim customer language captured in interviews, not from workshop sticky notes. Build the OST from interview data, not from team hypotheses.
Smoke tests measure intent to click, not willingness to pay or actual use - A high click-through rate on a "coming soon" landing page is a desirability signal, not a conversion signal. Users who click are curious; they have not committed to changing behavior, paying, or integrating the feature into their workflow. Smoke tests invalidate "no one wants this" but do not validate "people will pay and retain."
Using a high-fidelity prototype for flow testing anchors users on visual design - When a prototype looks production-ready, participants comment on button colors and copy instead of navigating authentically and revealing flow problems. For testing information architecture and navigation, deliberately use lo-fi wireframes. Reserve hi-fi prototypes for testing emotional response and design quality.
Kill thresholds defined after the experiment results are in are rationalization, not rigor - If you decide what "failure looks like" after you see the data, you will unconsciously set the threshold to preserve your preferred conclusion. Write the kill threshold - the specific metric result that would cause you to abandon or pivot the bet - in the experiment design document before the study begins.
References
references/experiment-playbook.md - Experiment templates by assumption type with
success criteria, sample sizes, and analysis guidance
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
