{
  "schema_version": 1,
  "skill_name": "product-discovery",
  "evals": [
    {
      "id": "stakeholder-map",
      "prompt": "We are starting discovery for a billing-system overhaul. I want to map who to talk to before scheduling any interviews. What does a complete stakeholder map look like and how do I decide who belongs in it?",
      "expected_output": "A stakeholder map that covers the full set of people whose needs and constraints shape the outcome: decision-makers who fund and approve scope, end users who operate the system day to day, operators and support staff who handle billing escalations, downstream teams who consume billing data (finance, sales ops, data), and adjacent system owners whose systems integrate with billing. For each stakeholder the map records their role, what they need from the system, what constraints they impose, and how their input could conflict with others. The response explains the selection criteria: include anyone whose unmet need would block adoption or whose assumptions would silently break the design if left unspoken.",
      "assertions": [
        "The response builds a stakeholder map covering decision-makers, end users, operators, downstream consumers, and adjacent system owners",
        "For each stakeholder the response captures needs, constraints, and potential conflicts",
        "The response gives selection criteria for who belongs in the map rather than an arbitrary list",
        "The response identifies where stakeholder interests conflict and how to surface those conflicts in discovery",
        "The response is specific to the billing-system context rather than a generic template"
      ]
    },
    {
      "id": "surface-hidden-assumptions",
      "prompt": "During interviews for our new reporting feature, stakeholders keep saying 'just like the current export, but better.' Nobody can define what better means. What questions should I ask to surface the hidden assumptions behind that phrase?",
      "expected_output": "A set of discovery questions designed to make the unstated assumptions explicit: what specific pain drives the request (which current export behavior is broken or slow), what outcome would count as success in measurable terms, who uses the export and for what decision, what the edge cases are that the current export handles badly (large files, empty data, formatting, timestamps in different timezones), what they would accept as a v1 versus what cannot wait, and what they would NOT want to change. The response frames each question to expose the underlying job and acceptance criteria, and it flags the pattern where vague phrasing signals either an unexamined assumption or an unstated constraint, then shows how to test the assumption by restating it and asking for confirmation.",
      "assertions": [
        "The response provides concrete questions that force definition of 'better' into measurable success criteria",
        "The questions probe who uses the output, for what decision, and which current behaviors are broken",
        "The questions surface edge cases and constraints the current export handles",
        "The response distinguishes v1 scope from deferred wants",
        "The response shows how to test an assumption by restating it and asking for confirmation"
      ]
    },
    {
      "id": "conflict-resolution",
      "prompt": "Two stakeholders disagree on the new checkout redesign: the payments team wants fewer steps to reduce abandonment, while the fraud team wants more verification to reduce chargebacks. Discovery is stuck. How do I resolve this without picking a winner politically?",
      "expected_output": "A conflict-resolution approach that treats the disagreement as a design constraint to be understood, not a battle to be won: first the response maps each stakeholder's underlying goal and the evidence behind it (abandonment data versus chargeback data), then looks for a resolution space that satisfies both — differentiating verification by risk tier, moving verification off the critical path to a background check, or adding a post-purchase verification step — and evaluates the options against both goals with the trade-off made explicit. The response keeps both stakeholders in the decision, documents the trade-off in the discovery output, and escalates only when the trade-off is genuinely unresolvable and requires a product decision, at which point it frames the decision for the accountable owner with the evidence on both sides.",
      "assertions": [
        "The response reframes the conflict as constraints to be designed against, not personalities to be managed",
        "The response maps each side's underlying goal and the evidence supporting it",
        "The response generates resolution options that serve both goals, such as risk-tiered verification or off-critical-path checks",
        "The response documents the trade-off and keeps both stakeholders in the decision",
        "The response frames escalation to the accountable owner as a last resort with evidence on both sides"
      ]
    },
    {
      "id": "gap-detection",
      "prompt": "We have written requirements for a mobile app feature but I suspect we are missing whole scenarios. The requirements cover the happy path in detail. How do I systematically find the gaps before we commit to a spec?",
      "expected_output": "A gap-detection procedure that walks the requirements against structured scenario categories rather than brainstorming: failure and recovery paths (what happens when the network drops, a payment fails, a sync conflicts), permission and entitlement states (users without access, expired sessions, shared accounts), boundary and empty states (no data, zero results, maximum data volume), multi-user and concurrency cases (two people editing the same object), and time-dependent behavior (timezones, midnight boundaries, scheduled jobs). For each category the response produces probe questions that turn into concrete scenarios, and it flags the highest-risk gaps for the feature at hand, such as offline-first behavior for a mobile app, and requires that the discovered gaps be added to the discovery output before spec sign-off.",
      "assertions": [
        "The response uses structured scenario categories such as failure paths, empty states, permissions, concurrency, and time boundaries",
        "Each category is turned into concrete probe scenarios rather than generic advice",
        "The response identifies the highest-risk gaps specific to a mobile app, such as offline and sync behavior",
        "The response requires discovered gaps to be captured in the discovery output before spec sign-off",
        "The response covers boundary states like zero results, maximum volume, and conflicting edits"
      ]
    },
    {
      "id": "translate-to-sdd-spec",
      "prompt": "Discovery is done for the notifications-center feature. I have interview notes, stakeholder maps, and a list of validated scenarios. Now I need to hand this off so it becomes a proper spec for the build pipeline. What should the handoff contain and how do I structure it?",
      "expected_output": "A structured handoff that translates discovery evidence into the inputs a spec pipeline needs: a problem statement grounded in the stakeholder evidence, the validated user scenarios written as concrete given-when-then behavior, explicit scope boundaries listing what is out of scope and why, unresolved questions and the owners for each, and the acceptance criteria per scenario that the implementation phase can verify against. The response explains the mapping from discovery artifacts to spec sections so the evidence trail stays intact — each requirement traceable to the interview or scenario that produced it — and it notes where the discovery output is incomplete and should not be silently papered over in the spec.",
      "assertions": [
        "The response structures the handoff around problem statement, validated scenarios, scope boundaries, and acceptance criteria",
        "Scenarios are written in concrete given-when-then behavior an implementation pipeline can verify",
        "The response keeps each requirement traceable to the discovery evidence that produced it",
        "Unresolved questions are listed with owners rather than silently resolved",
        "The response flags incomplete discovery areas instead of papering over them"
      ]
    }
  ]
}

# AI-Conducted Discovery

## When an AI Conducts Discovery Interviews

AI agents conducting discovery have unique failure modes that differ from human-led discovery. The most dangerous is sycophancy — the architectural tendency of RLHF-trained models to validate rather than challenge (Sharma et al. 2023, arXiv:2310.13548).

## Failure Modes

**Sycophancy:** Models are predisposed to agree with stakeholder statements. An AI asking "Wouldn't a dashboard be useful?" is structurally likely to validate the suggestion rather than probe it. The "are you sure?" problem means models abandon correct lines of inquiry after simple pushback.

**Confirmation bias in synthesis:** AI agents over-weight findings matching common training patterns (SaaS architectures, dashboard UIs) and under-weight novel or domain-specific requirements. They may hallucinate consensus where none exists.

**Leading questions through prompt structure:** Order effects, inference from prior context, and question framing steer conversations before the interviewer consciously chooses a direction.

**The trust paradox:** Stakeholders may be more honest with an AI (no social judgment) or less honest (dismissive, strategic self-editing, expectation of agenda).

## Mitigation Techniques

### Pre-Interview
- **Anti-sycophancy prompting:** "Your role is to challenge assumptions and probe for inconsistencies. Prioritize accuracy over agreement."
- **Bias audit of interview script:** Have a human review the question set for leading structure
- **Stakeholder priming:** Inform stakeholders the AI is programmed to challenge assumptions

### During Interview
- **Structured disagreement:** Offer counterpoints explicitly: "Some teams find that approach increases maintenance burden. Does that apply here?"
- **Multi-pass questioning:** Run the same topic from different angles; surface inconsistencies non-judgmentally
- **Triangulation questions:** Ask about the same requirement from different stakeholder roles

### Post-Interview
- **Confidence tagging:** Each finding carries a score based on consistency, specificity, and whether volunteered or elicited
- **Deviation reporting:** Explicitly call out where stakeholder testimony contradicts known data
- **Human review gate:** AI-conducted outputs must be reviewed by a human PM before acceptance
- **Stakeholder validation loop:** Share synthesized findings back before proceeding

## When the Spec Consumer Is Also an Agent

When discovery feeds directly into a coding agent (not a human team):

- **Precision requirements increase:** A coding agent cannot infer missing context. Every ambiguous statement produces random implementation.
- **No re-clarification loop:** The agent processes the entire spec in one shot. Include an ambiguity inventory flagging every point with multiple interpretations.
- **Explicit constraint encoding:** Non-functional constraints (compliance, architectural preferences, performance SLAs) must be first-class artifacts, not context.
- **Example-driven specs:** Coding agents benefit more from concrete input/output examples than abstract descriptions (CodeGen multi-turn research, Nijkamp et al. 2022).
- **Context window budgeting:** Most critical information (core behavior, key constraints) first; secondary details later.

## Sources

- Sharma et al. (2023) — "Towards Understanding Sycophancy in Language Models," arXiv:2310.13548
- Carro (2024) — "Flattering to Deceive," arXiv:2412.02802
- CodeGen (Nijkamp et al., 2022) — Multi-turn program synthesis, arXiv:2203.13474
- Anthropic (2025) — Persona vectors for sycophancy detection

# Conflict Resolution for Incompatible Requirements

## The Core Insight

Requirements conflicts are almost never about what they appear to be about. A surface-level disagreement is almost always a proxy for unstated differences in assumptions, risk tolerance, incentives, or values.

**Foundational reframe:** Treat requirements as hypotheses about what will solve the real problem. Conflicting requirements are competing hypotheses. The goal is not to pick the winner — it's to identify which assumptions differ and test those.

## The Conflict Spectrum

| Type | Definition | Resolution |
|------|------------|------------|
| **Preference conflict** | Taste, style, opinion | Test it — let data decide |
| **Value conflict** | Principles, risk tolerance, what matters | Must be named and addressed explicitly |
| **Incentive conflict** | Incompatible metrics | Restructure incentives or make trade-offs explicit |
| **Risk conflict** | Different risk tolerances | Map the risk portfolio and decide which to tackle first |

## Surfacing the Real Dimension

### The Ladder of Inference (Argyris/Senge)

For any conflicting requirement, ask in order:

1. **Data:** What observable facts does each stakeholder have?
2. **Interpretation:** What meaning do they attach to those facts?
3. **Assumptions:** What beliefs are they operating from?
4. **Conclusion:** What action follows from their assumptions?
5. **Beliefs:** What deeper values drive this?

Most conflicts resolve at Levels 1-3 with better data.

### The Assumption Test

For every conflicting requirement, ask: "What assumption would make this the right answer?" Then test that assumption, not the requirement.

## Facilitating Disagreement

**Lead with curiosity (Torres):** Assume the other person is smart and has good reason for their position. Your job is to find that reason.

**"How Might We" reframing:** Instead of "We should build X" (defense trigger), try "How might we achieve [outcome] given [constraint]?" (exploration trigger).

**One-on-one before group:** Meet stakeholders individually first to understand real concerns. One strong opinion derails group sessions.

**Show your work, not conclusions:** Share raw interview snapshots, early maps, messy prototypes. Stakeholders co-own what they helped shape.

## Synthesis Patterns

| Pattern | When | How |
|---------|------|-----|
| **Both/And** | Both serve different use cases | Sequence: A first, then B. Or A for current users, B for different tier |
| **Abstraction Ladder** | Both are examples of broader capability | Build the broader platform, satisfy both |
| **Horse Race** | Neither has strong evidence | Prototype both, test with real users |
| **Third Way** | Neither option works alone | "What addresses both concerns?" |

## Escalation Decision Matrix

| Situation | Escalate | Synthesize |
|-----------|----------|------------|
| Values genuinely incompatible | ✓ | |
| Time pressure; need direction | ✓ (for decision) | |
| Both untested; test is cheap | | ✓ (test both) |
| Conflict is about priority, not direction | | ✓ (sequence both) |
| One stakeholder blocking without data | ✓ | |
| Risk tolerance gap is wide | | ✓ (prototype riskiest parts) |

## Key Principles

1. **Conflicts are signals, not problems.** A conflict means an unstated assumption worth surfacing.
2. **Data resolves what opinions cannot.** Use customer data rather than arguing.
3. **The artifact is the alignment mechanism.** Externalize thinking in maps and prototypes.
4. **Treat every requirement as a hypothesis.** Defuses emotional investment and turns conflict into research.

## Sources

- Continuous Discovery Habits (Torres) — opportunity solution trees, assumption testing
- Inspired (Cagan) — product discovery principles, dual-track agile
- The Fifth Discipline (Senge) — Ladder of Inference
- Specification by Example (Adzic) — collaborative specification workshops

# Gap Detection During Discovery Conversations

## What to Listen For

### 1. Weasel Words

| Phrase | What It Signals | Follow-up |
|--------|----------------|-----------|
| "We should probably handle X" | Known gap not yet addressed | "What's the risk if we don't handle it?" |
| "Ideally it would..." | What they want vs. what they'll settle for | "What would make you settle for less?" |
| "In theory..." | Distance from practice | "What happens in practice?" |
| "Most of the time..." | Acknowledged exceptions | "Tell me about the times it doesn't work." |
| "We'll figure that out later." | Deferred decision | "What makes it hard to figure out now?" |

**Rule:** Every weasel word represents a gap. Your job is to convert the vague commitment into a specific condition.

### 2. The Abstract Noun Trap

Stakeholders use abstract nouns as shared shorthand. They are not shared.

| Abstract Noun | Decomposition Questions |
|--------------|----------------------|
| **Security** | "What data is involved? What's the worst-case exposure? Who regulates this?" |
| **Efficiency** | "What's being measured? What's the current value? What's 'efficient enough'?" |
| **Scalability** | "At what scale does the current approach break? What's the growth trajectory?" |
| **User-friendly** | "What's hard about the current system? Who struggles most?" |
| **Best practices** | "What specific practice are you thinking of? What outcome did it produce?" |

**Rule:** When you hear an abstract noun without context, you are hearing a gap. Convert values into falsifiable requirements.

### 3. Deferral Patterns

| Deferral | Likely Cause | Approach |
|----------|-------------|----------|
| "That's an X problem" across 3+ people | Organizational boundary issue | Surface explicitly: "Multiple people mentioned this as someone else's problem." |
| "We'll address that in Phase 2" | Hard problem that would delay current phase | "What would happen if Phase 2 never comes?" |
| Silence or topic change when X is raised | Political sensitivity | Follow up one-on-one |

### 4. Avoidance Signals

| Signal | Interpretation |
|--------|---------------|
| Overly quick agreement with everything | Politeness filtering — stakeholder is being agreeable, not honest |
| No pushback or clarifying questions | Stakeholder isn't fully engaged or is filtering |
| "I'm sure you'll figure it out" | Delegating responsibility, avoiding commitment |
| Topic that comes up in 1:1 but not in groups | Political sensitivity — power dynamics are suppressing the concern |

### 5. The Mom Test Framework (Fitzpatrick)

People will lie to you if they think it's what you want to hear. Three golden rules to get past polite feedback:

**Rule 1 — Talk about their life, not your idea.** ❌ "What do you think of this approach?" ✅ "Walk me through the last time you dealt with this problem."

**Rule 2 — Ask about specifics in the past, not hypotheticals.** ❌ "Would you use this feature?" ✅ "What did you do the last time this came up?"

**Rule 3 — Listen more than you talk.** Embrace awkward pauses — silence is where real insights surface.

**Bad data signals to watch for:**
| Signal | What It Means | Redirect |
|--------|---------------|----------|
| Compliments ("That's brilliant!") | Politeness | Acknowledge gracefully, redirect to facts |
| Hypothetical promises ("I'd definitely use that") | Zero commitment | Ask about past behavior instead |
| Enthusiasm without action | False positive | Ask for a concrete next step |
| Flat/"Meh" response | Honest signal | This is useful data — the problem may not be real |

## Follow-Up Techniques (Non-Defensive)

**The Columbo Technique:** Seem slightly confused, ask one more question at the door. "Just one more thing — you mentioned X. Help me understand that better." Works well when the stakeholder thinks the conversation is ending and lets their guard down.

**The Curiosity Frame:** Frame every probe as genuine curiosity, not challenge. "I'm trying to understand the full picture here. Can you walk me through how you see this working?"

**The Permission Check:** Before diving into a sensitive area. "Can I ask a question about that? I want to understand the reasoning." "Is this a good time to talk about the organizational side of this?"

**The Reframe:** When a stakeholder becomes defensive, reframe the gap as a shared problem. "I'm not criticizing the approach — I'm trying to figure out how to make it succeed." "The fact that this is hard to talk about probably means it's the most important thing to get right."

**The Empty Chair:** When someone is deferred to but absent. "What would [absent person] say if they were here?" "What questions would they ask that we haven't addressed yet?"

## Practitioner Reference

| Source | Key Technique | When to Use |
|--------|--------------|-------------|
| The Mom Test (Fitzpatrick) | Talk about past behavior, not future hypotheticals | Any discovery conversation |
| Skilled Incompetence (Argyris) | Name defensive routines neutrally; surface undiscussables | Organizational/political gaps |
| Interviewing Users (Portigal) | Probe what's unsaid; use contrasts to uncover frameworks | Deep qualitative interviews |
| Just Enough Research (Hall) | Focus questions on what you don't know; test assumptions | Early-stage discovery |
| Continuous Discovery Habits (Torres) | Opportunity solution trees; assumption mapping | Ongoing product discovery |
| The Secrets of Consulting (Weinberg) | "Randle's Rules" — observe what's NOT said | Consulting engagements |

## The Gap Detection Checklist

Before ending any discovery conversation:

- [ ] Did I hear any abstract nouns I didn't unpack?
- [ ] Did the stakeholder use weasel words? ("probably," "might," "eventually")
- [ ] Were any topics clearly avoided or deflected?
- [ ] Were any decisions deferred without a trigger, owner, or deadline?
- [ ] Am I carrying any tacit assumptions I haven't tested?
- [ ] Did I get compliments without specifics? (politeness signal)
- [ ] Did I ask about past behavior or future hypotheticals?
- [ ] Is there a person who wasn't mentioned who should have been?
- [ ] Did the stakeholder agree to something that seems too easy?
- [ ] What would need to be different for the stakeholder to tell me I'm wrong?

## Sources

- The Mom Test (Fitzpatrick) — talking about past behavior
- Skilled Incompetence (Argyris) — organizational defensive routines
- Interviewing Users (Portigal) — probing what's unsaid
- Ladder of Inference (Argyris/Senge) — climbing from data to conclusions

# Power Dynamics & Trust in Discovery

## The Hidden Variable

Every response in a discovery conversation is filtered through organizational hierarchy, political safety, and personal risk assessment. These filters are the single largest source of undetected error in product discovery.

## How Hierarchy Distorts Responses

**The HiPPO effect:** When a senior stakeholder is present, every other participant's answers shift toward alignment. Discovery findings converge on what the most powerful person wants, not what's true.

Signals: "As the VP said earlier...", glancing at senior person before answering, language shifts from "I need" to "We need."

**Fear of competence exposure:** Junior/mid-level stakeholders may hide workarounds, knowledge gaps, or the true time cost of current processes — especially when discovery is sponsored by leadership (perceived as audit).

**The "good soldier" problem:** Loyal stakeholders deliberately understate problems. They're not lying — they're acting out of loyalty.

## Mitigation Techniques

**Separate by power level.** Never interview junior stakeholders in a room with senior stakeholders present.

**Guarantee anonymity.** Make it clear specific statements won't be attributed. Aggregate findings to make attribution impossible.

**Frame as problem-finding, not blame-finding.** "We're looking for what's broken in the system, not what's broken in how anyone is doing their job." Repeat this framing.

**The "institutional distance" technique:**
- "What does the organization tend to get wrong about this process?" (not "what are you getting wrong?")
- "What would a new person in your role be surprised to learn?" (not "what did you miss?")

**Interview across the hierarchy gradient.** Interview stakeholders two levels above and one level below the primary target. The divergence reveals where hierarchy is distorting information.

**Pre-mortem for hierarchy:** After a senior person endorses a direction, the pre-mortem ("it failed — what went wrong?") gives junior stakeholders permission to raise concerns without contradicting authority directly.

## Trust Dynamics

Trust is set before the first question. Assess initial conditions:

- **High trust:** Stakeholders believe discovery is genuine, their input matters, they won't be harmed by honesty
- **Low trust:** Stakeholders believe the decision is already made, their input is performative, honesty carries personal risk

**Assessment question:** "What's your honest sense of how likely it is that this project will ship as planned?"

**If trust is low:** Acknowledge past failures, demonstrate responsiveness (share early findings to show input is acted on), and close the loop (commit to sharing what was learned and what decisions were made).

## Sources

- The Mom Test (Fitzpatrick) — getting past polite feedback
- Skilled Incompetence (Argyris) — organizational defensive routines
- Continuous Discovery Habits (Torres) — managing stakeholders

# Question Patterns for Discovery Interviews

## Core Principle

Closed questions confirm what you already think. Open questions discover what you didn't know to ask.

**Rule of thumb:** If the answer can be "yes" or "no," you're validating, not discovering.

## Question Pattern Catalog

### Story-Eliciting (highest signal density)

| Pattern | Example | Why It Works |
|---------|---------|-------------|
| **Tell me about a time** | "Tell me about the last time this process broke down." | Grounds in real experience |
| **Walk me through** | "Walk me through what you do when a new request comes in." | Surfaces steps too obvious to mention |
| **What happened next?** | Follow-up to any story | Extends narrative past comfortable stopping point |

### Assumption-Surfacing

| Pattern | Example | Why It Works |
|---------|---------|-------------|
| **What would have to be true?** | "For this to work, what would have to be true that isn't today?" | Exposes dependencies and preconditions |
| **Pre-mortem** | "It's a year from now and this failed completely. What went wrong?" | Surfaces risk without defensiveness |
| **The opposite** | "What would you do if we told you that approach won't work?" | Reveals real priorities |
| **Five whys** | Iterative "why" on any requirement | Traces surface want to root need |

### Laddering (Surface Want → Underlying Value)

1. **Attribute:** "What feature are you looking for?"
2. **Functional consequence:** "What would that let you do?"
3. **Psychosocial consequence:** "Why is being able to do that important?"
4. **Instrumental value:** "What does achieving that give you?"
5. **Terminal value:** "Deep down, why does that matter?"

**Only ladder the 2-3 most important items.** Don't ladder trivial features.

### Contrast Questions

| Pattern | Example |
|---------|---------|
| **Difference** | "How is this different from what you do today?" |
| **Absence** | "What would you do with unlimited resources?" |
| **Negative space** | "What would a bad solution look like to you?" |

### Validation Questions

| Pattern | Example |
|---------|---------|
| **Summarize and check** | "Let me make sure I understand. You're saying [summary]. Is that right?" |
| **Priority forcing** | "If you could only solve one of those problems, which one?" |
| **The disconfirming question** | "What would prove this theory wrong?" |

## Anti-Patterns

| Wrong | Right |
|-------|-------|
| "So you need a faster approval workflow?" | "Tell me about what happens when you need approval today." |
| "Would a mobile app solve that?" | "When this problem comes up, where are you?" |
| "Don't you think this is inefficient?" | "Walk me through the process." |

## The Question Stack Protocol

Design interviews as a stack from broad to narrow:

```
Level 1: Broad exploration — "Tell me about your work with [domain]."
Level 2: Problem discovery — "Tell me about a time things didn't work."
Level 3: Deepening — "Why does that matter?" (repeat as ladder)
Level 4: Assumption testing — "What would have to be true for that to work?"
Level 5: Validation — "Let me summarize what I'm hearing..."
```

Move down only when current level stops producing novel information.

## Socratic Questioning (6 Types)

From the Socratic method, six systematic categories for disciplined inquiry:

**Type 1 — Clarification:** "What exactly do you mean by 'better'?" / "When you say 'slow,' what threshold?" / "Help me understand the distinction you're drawing."

**Type 2 — Probing Assumptions:** "What are you assuming about the user's willingness to change?" / "Is this always the case, or only in certain situations?" / "What would need to be different for that assumption to be false?"

**Type 3 — Probing Evidence:** "What evidence do you have that this is the actual cause?" / "How do you know this is a widespread issue vs. isolated complaints?"

**Type 4 — Alternative Perspectives:** "How would customer support describe this problem differently?" / "Who benefits from keeping things as they are?" / "Is there another way to interpret this?"

**Type 5 — Implications:** "If we build this, what else changes downstream?" / "And then what happens?" / "What are the second-order effects of solving it this way?"

**Type 6 — Meta-Questions:** "Why are we asking about this feature instead of that one?" / "Whose question are we really trying to answer?" / "Is this the right question to be asking?"

## Tacit Knowledge Extraction

Stakeholders know more than they can tell. These techniques surface what they do automatically:

**Master-Apprentice:** "Pretend I'm the new person. Walk me through how you handle a typical escalation." "What took you the longest to learn that you now do automatically?"

**Think-Aloud:** "As you go through this process, please narrate what you're thinking." "What cue made you decide to do that step?"

**Critical Incident:** "Tell me about the most difficult case you handled last month." "Describe the last time you had to work around the system because it couldn't do what you needed."

**Artifact Walkthrough:** "Show me your system and walk me through what you do." "What's that spreadsheet you keep open that isn't part of the official system?"

## Interview Protocol Design

Structure interviews as a phased progression:

| Phase | Duration | Question Types | Goal |
|-------|----------|----------------|------|
| Warm-up | 5 min | Context: "Tell me about your role" | Build rapport |
| Walkthrough | 15 min | Process: "Walk me through yesterday" | Observe actual workflow |
| Pain points | 15 min | Incident: "Last time it broke" | Surface tacit knowledge |
| Latent needs | 10 min | Laddering: "Why does that matter?" | Surface underlying need |
| Assumption check | 5 min | Socratic: "What would have to be true?" | Test assumptions |
| Close | 5 min | Meta: "What did I not ask?" | Capture blind spots |

## Sources

- The Mom Test (Fitzpatrick) — past behavior over hypotheticals
- Laddering — Reynolds & Gutman (1988), Means-End Chain theory
- Socratic questioning — Paul & Elder (2006)
- Pre-mortem — Klein (2007)
- "What Would Have to Be True" — Lafley & Martin, Playing to Win
- Tacit knowledge extraction — Beyer & Holtzblatt, Contextual Design

# Stakeholder Mapping & Interview Sequencing

## The Discovery Role Quadrant

Before any interview, map stakeholders into four distinct roles:

| Role | Primary Question | Who This Describes |
|------|-----------------|-------------------|
| **Knowledge holders** | What's the problem? | Domain experts, support staff, power users, people who do the work daily |
| **Authority holders** | Is this worth solving? | Executives, budget owners, product sponsors, compliance |
| **Affected parties** | How will this change what they do? | End users, downstream teams, support, operations |
| **Implementation knowers** | Can we actually build this? | Engineers, architects, data owners, security, platform teams |

**Key rule:** Knowledge holders come first. Authority holders validate — they don't originate.

## Interview Sequencing

```
Phase A: Problem Discovery
  1. Knowledge holders (domain experts, support, power users)
     → What's broken? What do people actually need?

Phase B: Feasibility & Constraint Mapping
  2. Implementation knowers (engineers, architects, security)
     → What's technically feasible? What are the hard constraints?

Phase C: Validation & Commitment
  3. Authority holders (executives, sponsors, compliance)
     → Here's what we learned. Does this align with your priorities?
```

Affected parties (end users, downstream teams) should be consulted throughout, consulted in Phase A alongside knowledge holders.

## The Reverse Map

When you suspect missing stakeholders, work backward from impact:

- Who will have to change their workflow if this ships?
- Who will be asked to support or maintain the result?
- Who will lose something if this succeeds?
- Whose data or systems will be affected?
- Who has tried to solve this before and why did they fail?

## The "Three Questions" Per Interview

| # | Question | Purpose |
|---|----------|---------|
| 1 | "What's the biggest problem you're trying to solve?" | Surface their stake |
| 2 | "Who else should I talk to?" | Snowball sampling |
| 3 | "What would you do if you were in my shoes?" | Reveals assumptions about solution space |

## Common Patterns

**The one-stakeholder trap:** One person cannot represent an entire stakeholder category. Require minimum 3 sources per requirement category.

**The silent stakeholder:** The most important stakeholder is often the one who doesn't show up — the downstream team, operations, compliance. Ask "who else should we be talking to?" in every interview.

**The authority-first trap:** Natural instinct is to talk to the most powerful person first. This produces a spec that reflects their understanding — which may be outdated or politically colored. Authority holders go last.

## Output

For each stakeholder, produce a structured record:

```markdown
## Stakeholder: [Name / Role]
**Role type:** Knowledge / Authority / Affected / Implementation
**Key inputs:**
- Their understanding of the problem
- Their constraints and concerns
- Their definition of success
**Gaps noted:** What they deferred, what they didn't know
**Priority:** Must interview / Should interview / Optional
```

## Sources

- Power/Interest Grid: Mendelow (1981), Eden & Ackermann (1998)
- Stakeholder Salience: Mitchell, Agle & Wood (1997)
- Four-phase sequencing pattern: synthesized from practitioner sources

# Time-Constrained Discovery

## When Stakeholder Time Is Scarce

Not all questions produce equal signal. Prioritize the highest-density patterns.

## Signal Density Ranking

| Question Type | Signal | Why |
|--------------|--------|-----|
| Critical incident | Very high | Concrete, specific, grounded in real experience |
| Process walkthrough | High | Reveals actual workflow vs. stated workflow |
| Laddered need | High | Connects surface request to underlying value |
| Priority trade-off | High | Forces discrimination between competing needs |
| Feature wish | Low | List of wants without context |
| "What usually happens" | Low | Elicits idealized version, not reality |
| "Would you use X?" | Very low | Stated intent doesn't predict behavior |

**Time-saving rule:** Never ask questions in the bottom half of this table.

## The 15-Minute Interview Protocol

| Time | Activity | Goal |
|------|----------|------|
| 0-2 | Frame: "We need to understand X. I'll ask 3-4 quick questions." | Set scope |
| 2-7 | Single critical incident: "Walk me through the last time [problem] happened." | Most signal |
| 7-12 | Ladder one deep need: "What made that the worst part? Why does that matter?" | Surface root cause |
| 12-14 | Two assumption tests: "If we fixed that, what would change? What wouldn't?" | Test causality |
| 14-15 | Close: "What's the one thing I should have asked but didn't?" | Capture blind spots |

## The 3-Question Max (C-level / Executives)

1. **The problem question:** "What's the one thing about [domain] that keeps you up at night?"
2. **The evidence question:** "How do you know it's a real problem — what data tells you that?"
3. **The impact question:** "If we solved it, what would be different six months from now?"

These three cover: problem existence, problem validity, and desired outcome.

## The Asynchronous Discovery Kit

For stakeholders who can't schedule time:

- **Voice memo prompt:** "Record a 2-minute memo answering: what's the biggest obstacle to X in your daily work?"
- **Written prompt (200 words):** "Describe the last time [process] failed. Step by step. What was the worst part?"
- **Triage survey:** 5 forced-choice trade-offs (not Likert scales — those don't discriminate)

## The "One Thing" Protocol

1. "If we only do one thing in this project, what should it be?"
2. "If we do that one thing and nothing else, is it still worth doing?"

If the answer to #2 is "no," the real need is a bundle, not a feature. The requirement is more complex than stated.

## Red Flags: When Time Pressure Is Corrupting Discovery

- The "VP said it, so it's confirmed" pattern — senior opinions accepted without cross-checking
- The "we know the answer" shortcut — skipping discovery because the team "already knows"
- The "just add features" pattern — accepting every request without probing

## Sources

- Continuous Discovery Habits (Torres) — opportunity solution trees, assumption mapping
- The Mom Test (Fitzpatrick) — past behavior over hypotheticals
- Inspired (Cagan) — product discovery principles

# Transcript-to-Spec Distillation

## The Critical Bridge

This is where the most information loss occurs. Raw conversation notes enter one end; a structured SPEC.md exits the other. The methodology makes the translation visible and auditable.

## The 9-Step Workflow

### PREP: Before the Conversation
Load the gap detection reference to prepare for recognizing what stakeholders don't say.

### STEP 1: Segment the Transcript
Tag each utterance by type:

| Segment Type | Example |
|-------------|---------|
| **Statement of desire** | "We need to be able to export reports as CSV" |
| **Anecdote / narrative** | "Last week a customer spent 45 minutes trying to..." |
| **Rule / constraint** | "Only admins can delete projects" |
| **Hedge / weasel word** | "We should probably handle that eventually" |
| **Question** | "What happens when the payment fails?" |
| **Deflection** | Topic change, non-answer |

### STEP 2: Identify Candidate ACs Using Linguistic Markers

| Stakeholder Says | → | What It Yields |
|-----------------|---|----------------|
| "We need to [capability]" | → | 1:1 AC — explicit requirement |
| "When X happens, Y breaks" | → | Implied AC — inverse of complaint |
| "Only X can do Y" | → | Rule/constraint — needs positive + negative scenarios |
| "What about X?" | → | Edge case cue |
| "Remember when X happened?" | → | Error scenario — apply freeze-frame |

### STEP 3: Classify Each AC by Origin

| Category | Definition | Becomes |
|----------|-----------|---------|
| **SAID** | Explicitly stated by stakeholder | Direct AC |
| **IMPLIED** | Logically necessary for a SAID requirement | Infrastructure AC |
| **INTERPRETED** | Added by distiller from domain knowledge | Additional AC — flag for validation |
| **INFERRED** | Derived from a gap or avoided topic | Open Question — NOT an AC |

### STEP 4: Apply the Anecdote-Freeze-Frame Technique

For every anecdote, freeze at three points. Each freeze frame generates 1-2 ACs:

1. **FF1 — BEFORE:** State and user action preceding failure
2. **FF2 — DURING:** What happens during failure (system state, UX)
3. **FF3 — AFTER:** Outcome and what the user learns

**Ratio:** 1 anecdote → 3-5 ACs minimum.

### STEP 5: Convert to Given/When/Then

Use the "Friends Episode" naming convention — memorable titles stakeholders can recognize:

```
❌ "Validate pagination parameters when exceeding max limit"
✅ "The one where someone tries to export the whole internet"
```

### STEP 6: Flag Interpretation Risk

| Level | When | Action |
|-------|------|--------|
| **LOW** | AC maps 1:1 to explicit statement | Source attribution only |
| **MEDIUM** | Clear statement, but edge cases unstated | Flag in Open Questions |
| **HIGH** | Vague language, multiple interpretations | MUST validate with stakeholder |

### STEP 7: Identify and Log Conflicts

Cross-reference all AC candidates. Classify by type:

| Type | Example | Resolution |
|------|---------|------------|
| Genuine disagreement | Different stakeholders want different behaviors | Escalate to decision-maker |
| Role-dependent | Each role needs different rules | Role-based behavior is often correct |
| Temporal | "Now" vs "later" | Priority question |
| Terminology | Different meanings for same word | Agree on shared glossary |
| Assumption clash | Different beliefs about what's feasible | Translate to NFR threshold |

### STEP 8: Identify Gaps (Inferred Requirements)

Review the transcript for what stakeholders DID NOT discuss. Use the gap detection checklist:

- Abstract nouns never unpacked
- Decisions deferred without trigger/owner/deadline
- People absent from the conversation
- Edge cases that follow naturally from stated requirements but were never mentioned

Convert gaps to Open Questions, NOT to ACs.

### STEP 9: Validate with Stakeholders

- HIGH-risk interpretations → validate with original speaker first
- Conflicts → present to decision-maker with both positions documented
- Formalized ACs → run the "would you say yes to this?" test

## The Interpretation Audit Trail

Every AC in the spec should trace to a specific discovery artifact:

```markdown
### AC-001.1: Request generates confirmation
**Source:** Sarah (Support), quote: "The worst is when you submit and it just vanishes."
**Interpretation risk:** LOW — explicit concern about visibility
**Cross-reference:** Bob (Engineering) confirmed email notifications are feasible
```

## Sources

- Specification by Example (Adzic) — deriving executable specs from conversations
- Example Mapping — Wynne/Cucumber — 4-color card technique
- Deliberate Discovery (North) — learning as the constraint
- Acceptance Criteria vs Scenarios (Keogh) — rules vs. examples

# Discovery Plan: [Project Name]

## Stakeholder Map

| Name/Role | Type (Knowledge/Authority/Affected/Implementation) | Priority | Interviewed? |
|-----------|---------------------------------------------------|----------|-------------|
| | | Must / Should / Optional | |
| | | Must / Should / Optional | |
| | | Must / Should / Optional | |

## Interview Schedule

| Date | Stakeholder | Focus Area | Interviewer |
|------|-------------|------------|-------------|
| | | | |
| | | | |

## Key Questions Per Phase

**Phase A (Problem Discovery):**
- [Key questions for knowledge holders]

**Phase B (Feasibility):**
- [Key questions for implementation knowers]

**Phase C (Validation):**
- [Key questions for authority holders]

## Outputs

- [ ] Raw interview notes (all phases)
- [ ] Tagged transcript segments
- [ ] Candidate AC list with speaker attribution
- [ ] Conflict log
- [ ] Interpretation risk log
- [ ] Gap / open questions log
- [ ] Draft SPEC.md
- [ ] Stakeholder validation complete

# Distillation Worksheet: [Project Name]

## Section A: Segmentation Log

| Seg ID | Speaker | Segment Type | Verbatim Text | Notes |
|--------|---------|-------------|---------------|-------|
| S-001 | | | | |
| S-002 | | | | |

Segment types: statement-of-desire, anecdote, rule/constraint, hedge/weasel, question, deflection

## Section B: Candidate AC Log

| Cand ID | Seg Ref | Classification | Verbatim Source | Formalized AC | Risk | Notes |
|---------|---------|---------------|----------------|---------------|------|-------|
| AC-001 | S-003 | SAID | | Given...When...Then | LOW | |
| AC-002 | S-007 | IMPLIED | | Given...When...Then | MED | |
| AC-003 | S-012 | INTERP'D | | Given...When...Then | HIGH | Needs validation |

Classifications: SAID / IMPLIED / INTERPRETED / INFERRED

## Section C: Anecdote AC Mining

| Anecdote (verbatim) | Speaker | FF1: Before | FF2: During | FF3: After | Generated ACs |
|--------------------|---------|-------------|-------------|------------|--------------|
| | | | | | |

## Section D: Conflict Log

| Conflict ID | Source A | Source B | Topic | Type | Resolution | Decision Maker |
|------------|---------|---------|-------|------|-----------|---------------|
| C-001 | | | | | | |

Types: genuine-disagreement, role-dependent, temporal, terminology, assumption-clash

## Section E: Interpretation Risk Log

| AC ID | Source | Verbatim | Formalized | Risk | Validation Needed |
|-------|-------|---------|-----------|------|------------------|
| | | | | | |

## Section F: Gap / Open Questions Log

| Gap ID | Topic | What Was NOT Said | Why It Matters | Action |
|--------|-------|------------------|---------------|--------|
| G-001 | | | | |

# Gap Register: [Project Name]

## Unpacked Abstract Nouns

| Noun | Stakeholder Said | Decomposed Definition | Status |
|------|-----------------|----------------------|--------|
| | | | Pending / Resolved |

## Deferred Decisions

| Topic | Deferral Statement | Trigger (what turns "later" into "now") | Owner | Deadline | Status |
|-------|-------------------|----------------------------------------|-------|---------|--------|
| | | | | | |

## Avoided Topics

| Topic | Signal Observed | Stakeholder(s) | Possible Cause | Follow-up Plan |
|-------|----------------|----------------|---------------|---------------|
| | | | | |

## Missing Stakeholders

| Topic | Who Wasn't Consulted | Why It Matters | Action |
|-------|---------------------|---------------|--------|
| | | | |

## Unvalidated Assumptions

| Assumption | Source | What Would Disprove It | Status |
|-----------|--------|----------------------|--------|
| | | | Untested / Validated / False |

# Interpretation Log: [Project Name]

## AC Origin & Interpretation Tracking

| AC ID | Speaker | Verbatim Quote | Formalized AC | Origin | Risk | Status |
|-------|---------|---------------|---------------|--------|------|--------|
| | | | | SAID/IMPLIED/INTERPRETED/INFERRED | HIGH/MED/LOW | Pending/Validated/Revised |

## Key Interpretation Decisions

| AC ID | Stakeholder Said | Distiller's Interpretation | Alternative Interpretations Considered | Why This One Was Chosen |
|-------|-----------------|---------------------------|---------------------------------------|------------------------|
| | | | | |

## Validation Results

| AC ID | Validated By | Date | Result | Notes |
|-------|-------------|------|--------|-------|
| | | | Confirmed / Revised / Rejected | |

# Interview Guide: [Stakeholder Name/Role]

## Pre-Interview

**Stakeholder role type:** Knowledge / Authority / Affected / Implementation
**Domain(s):** [What they know about]
**Key questions to answer from this session:**
- [What do we need to learn from this person?]
- [What assumptions are we testing?]

## Question Stack

### Warm-up (5 min)
- "Tell me about your role and what you do day to day."

### Process Walkthrough (15 min)
- "Walk me through [specific process] from the beginning."
- Follow-up: "What happens next?"
- Follow-up: "What tells you it's time to start that step?"

### Pain Points / Critical Incidents (15 min)
- "Tell me about the last time this broke down."
- "What's the most frustrating part of this process?"
- "What workarounds have you developed?"

### Latent Needs (10 min)
- Laddering: "Why does that matter?" (repeat 2-3x)
- "What would have to be true for that to work?"

### Assumption Check (5 min)
- Summarize what you've heard and test interpretation
- "What did I miss?"

### Close (5 min)
- "What's the one thing I should have asked but didn't?"
- "Who else should I talk to?"

## Post-Interview

**Key inputs from this session:**
- [Capture the most important findings]

**Gaps noted:**
- [Weasel words, abstract nouns, deflections, deferred decisions]

**Follow-ups needed:**
- [Interpretations to validate, questions for next session]

**Signal density rating:** High / Medium / Low