When this skill is activated, always start your first response with the 🧢 emoji.

Product Discovery

Product discovery is the ongoing practice of learning what to build before - and while - building it. The goal is to reduce risk: shipping the wrong thing is far more expensive than the research that would have prevented it. This skill covers Jobs-to-be-Done (JTBD), opportunity solution trees, assumption mapping, experiment design, and prototype testing - giving an agent the judgment to run rigorous discovery the way a senior product manager or product trio would.

---

When to use this skill

Trigger this skill when the user:

• Asks how to apply Jobs-to-be-Done or conduct JTBD interviews
• Wants to build or review an opportunity solution tree
• Needs to map, categorize, or prioritize assumptions
• Is designing an experiment, A/B test, or validation study
• Wants to run or evaluate prototype tests (concept, usability, or value)
• Asks how to synthesize qualitative or quantitative discovery data
• Needs to establish a discovery cadence or dual-track workflow
• Is deciding between multiple product bets or solution directions

Do NOT trigger this skill for:

• Pure delivery execution (sprint planning, story writing, velocity - use agile-scrum)
• Growth hacking or marketing experimentation (use a growth or marketing skill)

---

Key principles

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Desired Outcome
  +-- Opportunity 1 (unmet need / pain / desire)
  |     +-- Solution A
  |     |     +-- Assumption 1 --> Experiment
  |     |     +-- Assumption 2 --> Experiment
  |     +-- Solution B
  |           +-- Assumption 3 --> Experiment
  +-- Opportunity 2
        +-- ...

Key rules:

• 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:

1. Assumption audit - List and stack-rank assumptions; no customer contact yet
2. Secondary research - Existing data, competitor analysis, academic studies
3. Customer interview - 30-60 min; 5-8 participants for a theme to emerge
4. Survey - Quantifies frequency of a qualitatively discovered pattern
5. Smoke test / landing page - Measures real intent without building the feature
6. Wizard of Oz - Manual fulfillment behind a product interface
7. Prototype test - Simulates the experience at chosen fidelity (paper, lo-fi, hi-fi)
8. Concierge MVP - Deliver the value manually; learn the job deeply
9. Technical spike - Validate feasibility assumption with a time-boxed build
10. 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):

1. Recruitment - Screen for people who have recently done the behavior you're studying. Recent = within 90 days. Avoid future-intent screening questions.

2. 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.

3. Dig into the struggle (15 min) - "What had you tried before? What was unsatisfying? What almost made you not switch?"

4. Outcomes and anxieties (10 min) - "What were you hoping would be different? What were you worried might not work?"

5. 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

1. Start with the outcome - Name the metric the product trio owns this quarter, e.g., "Increase week-2 retention from 42% to 55%."

2. 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.

3. Cluster and name - Group related struggles. Name them as customer problems ("I lose context when switching devices"), not solutions ("add cross-device sync").

4. Select the focus opportunity - Use impact/confidence/ease to compare. Pick one.

5. Brainstorm solutions - Generate 3+ candidate solutions per opportunity. Quantity over quality at this stage. Include unconventional ideas.

6. Map assumptions per solution - For each candidate, list what must be true for it to work. Sort by type (desirability/viability/feasibility/usability).

7. 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.

Synthesize discovery insights

Structure synthesis as: observation - pattern - insight - implication.

• 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

---

References

• references/experiment-playbook.md

  - Experiment templates by assumption type with success criteria, sample sizes, and analysis guidance

---

Related skills

When this skill is activated, check if the following companion skills are installed. For any that are missing, mention them to the user and offer to install before proceeding with the task. Example: "I notice you don't have [skill] installed yet - it pairs well with this skill. Want me to install it?"

• ux-research - Planning user research, conducting usability tests, creating journey maps, or designing A/B experiments.
• product-strategy - Defining product vision, building roadmaps, prioritizing features, or choosing frameworks like RICE, ICE, or MoSCoW.
• customer-research - Conducting customer research - designing surveys, writing interview guides, performing...
• user-stories - Writing user stories, defining acceptance criteria, story mapping, grooming backlogs, or estimating work.

Install a companion:

npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>