product-skill/ PRO/ Discovery PRO depth

PRO: Discovery · the tree, the tests, the House

Every node ladders to the one above it; every leaf is a test, not a feature.

The worked depth behind §Discovery: templates, scripts and decision bars you paste and fill — a verbatim interview guide, a populated Opportunity Solution Tree, riskiest-first assumption testing, and the QFD House of Quality. All numbers illustrative unless a source is named.

Outcome (root · one measurable behavior) Lift week-1 activation — first successful data export — 34% → 50%

Opportunities — needs in the customer's words · mention-counts from ~20 interviews

O1 · work first "I couldn't tell if my import actually worked" 12 / 20

O2 · parked "I didn't have my data file ready when I signed up" 7 / 20

O3 · parked "The sample template didn't match my use case" 5 / 20

Solutions branched under O1 — diverge: competing, not one idea ×3

S1 · progress bar + success/failure screen

S2 · inline validation preview

S3 · concierge white-glove import

S4 · (AI) auto-map columns to schema

Assumption tests — the leaves · riskiest first

S4 · Model-Capabilitygolden-set eval ≥90% correct maps on 50 files

S3 · Viabilitymargin model — time-per-import × volume

S1 · Desirability5-user prototype task

Opportunity Solution Tree (Torres) — outcome down, evidence up. A tree with two roots is two trees.

Above the fold

Three disciplines that keep the tree honest.

01

Run it as a system, not a study.

A standing weekly cadence: ≥1 customer touch → ≥1 opportunity updated → ≥1 assumption test in flight. A week with zero customer contact is the bug. Recruiting is the silent killer — automate it.

02

Mine stories, not opinions.

People can't predict future behavior or design your product; they can recount what they actually did. Every question anchors to one recent, specific instance. The workaround they hired is the demand signal.

03

Pre-commit the pass bar.

Write the threshold and the decision it triggers before you run the test, or you'll rationalize whatever number you get. Riskiest-first is necessary — then Wizard-of-Oz the integrated flow before full build.

§1–2 · the cadence and the guide

A standing loop, and a script that collects stories.

Torres · the weekly loop

Discovery is a cadence the Trio owns, not a phase before build

Every week: ≥1 customer touch (interview, observed session, or support-ticket read) → ≥1 opportunity added/updated on the tree → ≥1 assumption test in flight. If a week passes with zero customer contact, that's the bug — fix the cadence before fixing any feature.

Recruiting is the silent killer. Set up automated, continuous recruiting (in-app "talk to us" triggered on a relevant action, a rolling panel, a recruiter cadence) so you never have to start finding people. Target a steady trickle (1–2/wk) over a quarterly batch of 20.

Who you talk to is the result. Recruit on recent behavior ("did the job in the last 2 weeks"), not volunteers or your friendliest power users — a panel skewed to fans produces a tree skewed to confirmation.

Torres · story-based interviewing

The interview guide — paste and fill (verbatim)

Collect specific past stories, not opinions or feature wishlists. Every question mines a concrete, recent instance.

SETUP (90 sec): "There are no right answers — I'm here to learn how you actually work, not to demo anything. Mind if I record so I don't miss details?" CONTEXT (warm-up, 2–3 min): "Walk me through your role and what a typical [relevant period] looks like." THE STORY (the core — anchor to ONE recent real instance): "Tell me about the LAST time you [did the job / hit the situation]." → for churn/abandonment: "...the last time you opened [product] and then stopped before finishing — what was going on?" Then stay in that story with WHAT-happened probes, NOT why-opinion probes: - "What were you trying to get done right before that?" - "What did you do next? ...and then?" (walk the timeline step by step) - "Show me / where were you / what else was open?" (recreate the scene) - "Last time that happened, what did you do instead?" (workaround = demand signal) - "What made you finally decide to [act]?" (trigger / push) - "What almost stopped you?" (anxiety / inertia — see Four Forces) EXTRACT (do NOT skip): before ending, name back the moments of friction you heard and confirm: "So the painful part was [X] — is that right?" CLOSE: "Who else lives this problem that I should talk to?" (snowball recruiting)

Interviewing anti-patterns — each invalidates the data

• Asking "what features do you want?" or "would you use X?" — pitching, not discovering. You've contaminated the session into solution-validation theater.

• Letting them generalize ("I usually…") — pull them back to the specific last time. Generalizations are reconstructed opinion; stories are evidence.

• Leading ("don't you find X frustrating?") — you'll get agreement, not truth.

• Taking interpreted notes. Capture verbatim moments and quotes; interpretation happens in synthesis, against the transcript — never against the AI's or your own summary.

§3 · outcome down, evidence up

Build the Opportunity Solution Tree in order.

The OST is a living artifact. The discipline: every node ladders to the node above it. Attack one opportunity at a time — don't boil the tree.

Torres · Perri (Product Kata) · Ulwick (ODI)

Five steps — and the ODI score for a defensible ranking

Step 1 — anchor the single outcome at the root. One product outcome (a measurable behavior change), not a business metric and not a feature. "Increase weekly active teams" ✓; "ship collaboration" ✗ (a solution); "grow revenue" ✗ (translate it down to the product behavior that drives it).

Step 2 — populate opportunities from interview snippets (evidence up). An opportunity is a need, pain or desire in the customer's words, never a solution in disguise. "A faster export" is a solution; "I lose the thread when I have to leave the app to share results" is the opportunity. De-dupe into a hierarchy; keep each snippet→opportunity link traceable.

Step 3 — size, then pick ONE. Rank by importance × prevalence × strategic fit. Lightweight for weekly steering; ODI when you need a defensible, quantified ranking for a roadmap argument:

Ulwick opportunity score = importance + max(importance − satisfaction, 0)

High-importance / low-satisfaction outcomes are underserved → the real opportunities. High-importance / high-satisfaction = table stakes (don't over-invest). Low-importance = ignore, or overserved (candidates to cut).

Step 4 — branch 2–3 competing solutions under the chosen opportunity (diverge before converge). A single-branch tree means you're committed, not discovering.

Step 5 — drop assumption tests under each solution. The leaves are tests, not features. Product Kata plugs in here: outcome → current state → target condition → obstacle (the chosen opportunity) → experiment (the leaf). Skipping the target condition and jumping root→solution is the classic kata failure.

Worked — B2B SaaS activation (all numbers illustrative)

Outcome: lift week-1 activation (new accounts that complete a first successful data export) from 34% → 50%.

Opportunities: O1 "I couldn't tell if my import actually worked" — 12/20 (highest prevalence + emotion → work first); O2 "I didn't have my data file ready" — 7/20; O3 "The sample template didn't match my use case" — 5/20. O1 chosen; O2/O3 parked, not deleted.

Solutions under O1: S1 progress bar + success/failure confirmation · S2 inline validation preview ("row 14: invalid date") · S3 concierge white-glove · S4 (AI) LLM auto-maps columns to schema.

Tests (riskiest first): S4 = Model-Capability → offline golden-set eval before any UI, bar ≥90% correct column maps on 50 real files · S3 = Viability → margin model · S1 = Desirability/Usability → 5-user prototype. Then pre-mortem the winning branch and run one end-to-end Wizard-of-Oz of the whole import flow before full build.

Model-Capability leaf → pro §ai-evals · ODI ranking pairs with Kano → §Prioritization

§4–5 · the riskiest-first engine, and the irreversible-bet check

Surface the bets, test the riskiest cheaply, pre-mortem the one-way doors.

Assumption-test design

A solution is a bundle of bets — rank by risk, test the riskiest first

Step 1 — decompose into assumptions by category:

Category	The bet	"We're betting that…"
Desirability	they want it	users care enough to change behavior
Viability	works for the business	it doesn't break revenue / cost / legal / strategy
Feasibility	we can build it	eng can integrate/ship it in our constraints
Usability	they can use it	users can find and operate it without help
Model-Capability (AI)	the model is good enough	the model does this job on our data at the bar — test on a golden set before any UI

Step 2 — map on importance × evidence. Plot how much the solution depends on the assumption (importance) against how much evidence you already have. Test the high-importance / low-evidence corner first — the leap-of-faith assumptions that sink the solution if wrong. Don't re-prove what you already have evidence for.

Step 3 — pick the cheapest test that can produce a NO:

Riskiest assumption	Cheap test	What a NO looks like
Desirability	painted/fake-door, landing-page intent, concierge offer	intent rate ≤ baseline
Usability	unmoderated prototype task, 5-user think-aloud	users can't complete the core task
Feasibility	eng spike / tech prototype on real constraints	can't hit latency/integration bar
Viability	WTP probe, margin model, compliance review	unit economics or legal won't clear
Model-Capability	offline eval on a labeled golden set	accuracy/quality below the pre-set bar

Step 4 — pre-commit the pass bar BEFORE running (write the threshold + decision first, or you'll rationalize):

Assumption: We believe [X is true]. Risk if wrong: [what breaks]. Current evidence: [none / weak / strong]. Test: [method] with [N] [target-segment] users. Pass bar (pre-committed): [metric] ≥ [threshold] → proceed; below → revise/kill. Run by: [date]. Owner: [Trio member].

Step 5 — guard the two traps:

(1) Each assumption can pass alone yet the whole flow fails. Riskiest-first is necessary, not sufficient. Before full build, run an end-to-end concierge / Wizard-of-Oz (you manually deliver the outcome behind a real-looking front end) to test the integrated experience and the value, not just the parts.

(2) Don't out-discover a reversible bet. For a small, low-cost, Type-2 change, shipping behind a flag is the experiment — discovery theater on a one-way-cheap decision is wasted weeks. Reserve full rigor for irreversible or expensive bets.

Desirability test = painted-door → pro §growth §4 · Model-Capability → pro §ai-evals

Klein · Doshi in PM

Pre-mortem the irreversible bet — written-first, independently

Before committing to a Type-1 / one-way-door solution off the tree, run a pre-mortem — not on every sprint, only when irreversibility is real (data model, pricing change, public API, regulated flow).

Frame: "It's 6 months out. We shipped this and it failed. Write down why." Written-first, independently — everyone writes before anyone speaks, which kills the groupthink that makes a confident team blind to its own riskiest assumption.

Cluster the failure modes → the top 2–3 become new assumption tests on the tree (this is how a pre-mortem feeds §4 rather than just generating anxiety). In regulated/fintech/health contexts, put Compliance in the room — consent, adverse-action and safety failure modes are gating, not advisory.

§6–7 · causal understanding, then the no-build filter

Diagnose the switch — then make it clear the bar.

Christensen · JTBD + Four Forces

Layer JTBD onto the story for causal "why," not a pain list

Job statement from the story: "When I [situation], I want [motivation], so I can [outcome]." Frame the job around the circumstance, not your product category — the Milkshake competes with a banana and boredom, so ask what they actually hired and fired to make progress.

Four Forces timeline — reconstruct the switch moment and tag each force:

drives toward new →

Push

of the old situation — what's no longer tolerable

drives toward new →

Pull

of the new solution — the promised progress

← holds back

Anxiety

about the new — fear of the unknown, switching risk

← holds back

Inertia / habit

of the current way — the comfort of the status quo

For a new feature class, anxiety + inertia are usually the dominant blockers — so the insight is "reduce friction/risk," not "add more pull." For churn, run the forces backwards: what pushed them off you, what pulled them away.

Consumption job ≠ purchase job — interview the moment of use, not just the buy; durable churn hides in the consumption job. Three job types (functional / emotional / social) — probe all three; emotional and social are the ones surveys miss.

The Udezues · Building Rocketships (2025)

The build gate — sharp-problem test + Zone-of-Benefit

Before an opportunity earns build, it must clear a sharpness bar — the no-build filter that keeps the tree honest. It sits between OST Step 3 (opportunity chosen) and Step 4 (solutions branched).

Sharp problem, judged multi-signal: (a) workflow compression — your solution collapses many painful steps into few; AND (b) a visceral, in-interview "I need this now" — not polite interest. Both signals, not one. A diffuse or merely-agreeable problem → keep discovering, don't build.

Zone-of-Benefit bar: aim to be ≥3× better on the one dimension the customer actually feels (speed, effort, cost — whichever the stories centered on), not 3× on a spec they don't notice. The 3× is illustrative — the real test is "noticeably, switch-worthy better on the felt dimension."

Diffuse signal + weak differentiation is the single most common reason a well-built feature lands flat.

§8–9 · capture as you go, and keep AI honest

Synthesize continuously, against the transcript.

Synthesis & the interview snapshot

One snapshot per interview — map, don't list

Synthesize continuously, one snapshot per interview, against the transcript — not in a big-bang readout weeks later (by then the specifics have decayed into your bias).

WHO + CONTEXT: [role, segment, did-the-job-when] THE STORY: situation → step-by-step sequence → where it broke VERBATIM QUOTES: "[exact words — the friction + the emotion]" OPPORTUNITIES SURFACED: [needs in their words, solution-agnostic] EXISTING WORKAROUND / ALTERNATIVE: [what they hired instead = demand signal]

Roll-up onto the tree: cluster snapshots into opportunities; track mention counts as a rough size signal (directional — small-n, not a survey; don't over-read a single mention). Saturation ≈ when new interviews stop adding new opportunities — that's your "enough for now," not a fixed N.

Map, don't list. The OST is the synthesis artifact; a flat "findings" list loses the outcome→opportunity→solution lineage and lets pet solutions sneak back in unattached.

Torres · AI-era discovery (2024–26)

AI is a research assistant, not the researcher

AI accelerates synthesis but used naively it manufactures false confidence.

• It misses ~20–40% of opportunities/insights (directional — not a measured constant): keep a human in the loop and treat AI synthesis as a first pass to verify, never the source of truth.

• Decompose the prompt. A monolithic "do my user research" prompt buries failures. Break it into narrow steps (extract verbatim pains → cluster → phrase as needs) you can inspect at each stage.

• Run the error-analysis loop like eval traces: read AI outputs → code where it failed → fix the prompt → re-run.

Verify against raw transcripts, never the AI's summary. The summary is where hallucinated or flattened insight enters; the transcript is the evidence.

Error-analysis loop → pro §ai-evals

§10 · voice of the customer → measurable spec

Quality Function Deployment — the House of Quality.

The bridge from interviews (voice of the customer) to engineering targets that survive the handoff. Kano categorizes features; QFD translates them into specs and trade-offs — a different job. HIGH

Roof · EC × EC trade-off grid

③ Ceiling

Engineering characteristics — the "hows" in measurable units

measurable AND directly felt

door weight is an EC; sheet-metal thickness is a part characteristic the customer never perceives

① Left wall

Customer attributes — needs in their own words ("easy to close"); preserve the clichés

④ Body · relationship matrix

strength of each EC↔attribute link. EC linked to no attribute = redundant; attribute linked to no EC = whitespace

② Right wall

Importance + competitive benchmark — this wall is a perceptual map

⑥ Basement · targets

set each as a customer-satisfaction value — "7.5 ft-lb," not "between 6 and 8" (tolerance language rewards drift to the cheap end)

Build order: left wall → right wall → ceiling → body → roof → basement. The roof is the most critical room.

Hauser & Clausing · HBR May 1988

Arbitrate, don't average — the car-door example

Same chart, opposite calls, driven by importance × competitive position × roof trade-off, not gut:

Fix the door: doors harder to close than competitors' + that attribute is important + the roof shows the fix drags other specs → marketing + engineering + GM jointly decide the benefit wins → target 7.5 ft-lb.

Leave the road noise: "no road noise" is mildly important, we already lead, and the fix hurts higher-priority attributes → don't touch it.

Cascade: the "hows" of one house become the "whats" of the next (product → parts → process → production), so the customer's voice can't drift across handoffs. (Originated 1972 at Mitsubishi's Kobe shipyard; early use cut Toyota Auto Body startup/preproduction cost >60% between 1977 and 1984.)

Software translation · when NOT to draw the full house

Software translation: customer attributes = the ranked opportunities off the OST; ECs = measurable system behaviors (p95 latency, time-to-first-value, error rate); the roof = architecture trade-offs (cache freshness vs write cost; recall vs precision). The discipline that ports: set targets as satisfaction values, not ranges, and surface the roof trade-off before committing the spec — most "the feature shipped but something else got worse" misses are unmapped roof effects.

When NOT to draw the full house: it's heavy — reserve the full grid for multi-team, high-coordination, expensive-to-change builds (hardware, regulated, platform). For a small reversible software bet, borrow the relationship-matrix thinking (which spec serves which ranked need, what it trades against) without drawing the chart.

Keep reading