pm-discovery

name	pm-discovery
version	0.1.0
description	Product discovery. Figures out WHAT to build before you plan HOW to build it. Maps the opportunity space, surfaces the riskiest assumptions, and designs the cheapest tests. Run this before pm-challenge-me when you're pre-product, pivoting, or unsure if a feature is right.
allowed-tools	Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, Agent, WebFetch

Multi-host portability rules. When invoking AskUserQuestion:

1. The header field MUST be a short noun phrase (≤ 12 characters). Mistral Vibe rejects longer headers with string_too_long. Pick from: Start, Target, Scope, Audience, Methodology, Feature, Question.
2. The options list MUST have at least 2 items. Vibe rejects empty/single-option calls. For free-text input, always provide ≥ 2 framing options (e.g. Yes, here's the input / Skip) — never call ask_user_question with options: [].

Two modes

This skill has two modes. Pick based on what the user is asking for:

• Map mode (default): the full discovery flow below (Phases 1–7). Maps the opportunity space, inventories assumptions, designs the cheapest tests, and writes the wiki Discovery page.
• Interview-prep mode: the user wants a hypothesis-driven user-interview guide to take into a live call — a prep deliverable, not a discovery analysis. Jump to the Interview-prep mode section near the end and produce the guide there. Prep mode does not write to the wiki or the opportunity database; it only hands the human a ready-to-run guide. (Capturing what an interview returns — transcript import, signal extraction, feedback writeback — is /pm-add-feedback's job, not this skill's.)

If it's ambiguous, default to Map mode and offer prep mode at the end.

Preamble (run first)

source ~/.nanopm/lib/nanopm.sh 2>/dev/null || \
  source .nanopm/lib/nanopm.sh 2>/dev/null || \
  { echo "ERROR: nanopm not installed. Run: curl -fsSL https://raw.githubusercontent.com/nmrtn/nanopm/main/setup | bash"; exit 1; }
nanopm_preamble

When to run this

Run /pm-discovery when:

• You're pre-product and unsure what to build
• You're considering a new feature and want to validate it first
• You're pivoting and need to re-examine the problem space
• pm-challenge-me gave you a strategic gap you don't know how to close

Run /pm-challenge-me when you already know what you're building and want to assess it.

Phase 0: Prior context

source ~/.nanopm/lib/nanopm.sh 2>/dev/null || source .nanopm/lib/nanopm.sh 2>/dev/null || true
nanopm_context_read pm-discovery
nanopm_context_read pm-discovery

If prior discovery entry found: "Prior discovery from {ts}. This run will build on it."

Phase 1: Scope the discovery

Ask via AskUserQuestion to frame the discovery question. Multi-host hosts (Vibe, Codex) require ≥2 options — provide a category picker, then collect the specific question as free-text in the chat after.

• question: "What kind of discovery are you running? After you pick, I'll ask for your specific question."
• header: Scope (≤12 chars)
• multiSelect: false
• options:
  • A) "Build-vs-don't" — should we build X feature, and if so for whom?
  • B) "Why users churn" — why are users dropping at step N or stage Z?
  • C) "Market exists?" — is there demand for product Y at a price?
  • D) "What next?" — among several candidates, what's the highest-value to build?
  • E) "Direction check" — is our current strategy still right given new signal?
  • F) "Other (specify)" — describe your discovery question in the next message

After the choice, prompt directly (no tool call): "OK, you picked {category}. Now state the specific question this discovery should answer, in one sentence." Capture that as _DISCOVERY_QUESTION.

This answer scopes everything that follows. Don't proceed with a vague answer — push for a specific question the discovery should answer.

Phase 1.5: Surface existing wiki context

With _DISCOVERY_QUESTION captured, search the wiki for related opportunities and personas before mapping the opportunity space — so this run builds on existing context rather than starting from zero.

source ~/.nanopm/lib/nanopm.sh 2>/dev/null || source .nanopm/lib/nanopm.sh 2>/dev/null || true
nanopm_wiki_search "$_DISCOVERY_QUESTION" opportunity 5

source ~/.nanopm/lib/nanopm.sh 2>/dev/null || source .nanopm/lib/nanopm.sh 2>/dev/null || true
nanopm_wiki_search "$_DISCOVERY_QUESTION" persona 3

For each result, Read the full page (path column) before Phase 2. Never act on the 200-char summary — the page body carries related evidence, provenance, and cross-links. If the searches return NO_RESULTS, proceed as if no prior context exists. Fire 2–3 keyword variants if phrasing of _DISCOVERY_QUESTION is abstract.

Phase 2: The job to be done

Ask as SEPARATE sequential AskUserQuestion calls — one call per question, never batched. Wait for the answer before asking the next. Skip if clearly answered by context.

Before Q1, pull the primary persona through the query primitive — one read-side call that synthesizes the relevant wiki pages, instead of a bespoke per-doc read (the recipe pattern: query → reasoning → ingest). The raw page stays out of this run; you reason over the cited synthesis the query returns. Print the prompt and dispatch it with the Agent tool (one subagent); on a host with no Agent tool, follow its steps inline.

source ~/.nanopm/lib/nanopm.sh 2>/dev/null || source .nanopm/lib/nanopm.sh 2>/dev/null || true
nanopm_query_prompt "For product discovery, synthesize from the wiki: the primary persona this product is built for — their job title, situation, and the job-to-be-done they hire the product for; the current top-ranked open opportunities from the opportunity database (wiki/entities/opportunities/, by rank); the top open user-feedback themes; and the current product surface. Cite each claim, and name what's missing rather than inventing it." none

Reason over the returned synthesis:

• If a primary persona is named: use it to pre-fill Q1 — confirm it rather than asking cold: "The personas page says you're building for {primary persona}. Still the focus for this discovery, or are we exploring a different user?"
• If the synthesis reports no personas page: ask Q1 cold, and if the discovery lands on a sharp user definition, recommend /pm-personas to formalize it at the end.

Q1: Who is the user you're focused on? "Describe the specific person you're trying to help. Not a category — a person. Job title, company size, situation they're in when they reach for your product. e.g., 'a solo founder about to hire their first sales rep' or 'an ops manager at a 50-person logistics company who's still running dispatch in a spreadsheet.'"

Push if the answer is categorical ("SMBs", "developers"). Ask: "Can you name an actual person — or describe someone you've talked to who fits this?"

Q2: What is the job they're hiring your product to do? "When they use your product, what are they really trying to accomplish? Not the feature — the outcome. What does success look like for them? e.g., 'stop worrying that something fell through the cracks' or 'look competent in front of their VP.'"

This is the functional + emotional job. Push past "use the feature" to what changes in their life.

Q3: What are they doing instead right now? "If your product doesn't exist — or doesn't cover this need — what do they do? The specific workaround. The spreadsheet. The Slack thread. The hiring of a person. What does that workaround cost them in time, money, or pain — and how often does the pain occur?"

This is the most important question. If the answer is "nothing" — probe harder. Someone solving a real problem always has a workaround, even if it's denial.

Q4: What would have to be true? "For your solution to win, what would have to be true about the user, the market, or the problem? List 2-3 beliefs your plan depends on. e.g., 'users are willing to pay $X/month for this', 'the workaround is painful enough to change behavior', 'the decision-maker and the user are the same person.'"

Stop after all four are answered. Don't ask more than four questions in this phase.

Phase 3: Opportunity mapping

Synthesize the answers into an opportunity map. For each stated user job and workaround, identify:

Underserved outcomes — jobs the user is trying to do that existing solutions address poorly. Rate each: High / Medium / Low underservice.

Anxiety — what makes users hesitant to switch or adopt? (switching cost, trust, habits)

Constraints — what limits the solution space? (budget, tech, team size, time)

Do NOT propose solutions yet. Map the opportunity space only.

Phase 4: Assumption inventory

List all the assumptions the discovery direction rests on. For each, rate:

• Importance (1-5): how much does the strategy collapse if this is wrong?
• Confidence (1-5): how much evidence do you have that it's true?
• Risk score: Importance × (5 - Confidence) — higher = test this first

Format:

Assumption	Importance	Confidence	Risk	Source
{belief}	{1-5}	{1-5}	{score}	{where it came from}

Sort by risk score descending. The top 2-3 are what discovery must address.

Phase 5: Test design

For each high-risk assumption (top 3 from Phase 4), design the cheapest possible test:

Test design format:

Assumption: {the belief}
Risk score: {N}

Cheapest test:
  What: {one specific action — not a project, an action}
  Who: {who you need to talk to or observe}
  Time/cost: {how long and what it costs}
  Signal: {what result confirms the assumption}
  Counter-signal: {what result would refute it}
  Verdict by: {date — no more than 2 weeks out}

Examples of cheap tests:

• 5 user interviews asking about the workaround (not demoing the solution)
• A fake door / landing page with a "sign up" button that measures intent
• Offer to do the job manually (concierge MVP) before building anything
• Check if competitors' reviews mention this pain in the top complaints
• Ask a current user: "If we removed this feature tomorrow, what would you do?"

Avoid: building anything, running surveys to hundreds of people, waiting for "enough data."

Phase 6: Write the wiki Discovery page

Write $(nanopm_wiki_doc_path discovery) (.nanopm/wiki/docs/discovery.md). Begin the file with frontmatter from nanopm_wiki_doc_frontmatter pm-discovery user-stated "$(date +%Y-%m-%d)" "{sources}", then the body below:

# Product Discovery
Generated by /pm-discovery on {date}
Project: {slug}
Discovery question: {from Phase 1}

---

## The User

{Who they are, what job they're hiring a product to do, emotional + functional outcome.
Specific enough that you could email this person.}

---

## The Status Quo

{What they do today when the solution doesn't exist or doesn't fit.
The workaround, its cost in time/money/pain, and how often it occurs.}

---

## Opportunity Space

{2-3 underserved outcomes from Phase 3. Each rated High/Med/Low.
Not solutions — observations about where the pain is greatest and why existing approaches fall short.}

---

## Assumption Inventory

| Assumption | Importance | Confidence | Risk | Source |
|------------|-----------|------------|------|--------|
{rows from Phase 4, sorted by risk}

---

## Tests to Run

### Test 1 (highest risk assumption)
{test design from Phase 5}

### Test 2
{test design from Phase 5}

### Test 3 (if needed)
{test design from Phase 5}

---

## What NOT to build yet

{Explicitly: what directions this discovery ruled out, or put on hold until tests return results.
Building before the top assumptions are tested is how startups waste 6 months.}

---

## Recommended Next Skill

**Run tests first. Then: /pm-challenge-me**

Once the top 2-3 assumption tests return results, run /pm-challenge-me with the validated understanding
of who the user is and what they actually need. The challenge session will be significantly sharper.

{If tests already run / evidence already exists: "Evidence is sufficient — run /pm-challenge-me now."}

---

*Sources: user answers, prior context, opportunity analysis*

Phase 7: Save context

source ~/.nanopm/lib/nanopm.sh 2>/dev/null || source .nanopm/lib/nanopm.sh 2>/dev/null || true
nanopm_context_append "{\"skill\":\"pm-discovery\",\"outputs\":{\"discovery_question\":\"$(head -5 \"$(nanopm_wiki_doc_path discovery)\" | grep 'Discovery question' | cut -d: -f2- | xargs | tr '\"' \"'\" | head -c 100)\",\"top_risk\":\"$(grep -A1 'Assumption Inventory' \"$(nanopm_wiki_doc_path discovery)\" | tail -1 | tr '\"' \"'\" | head -c 100)\",\"next\":\"pm-challenge-me\"}}"
nanopm_wiki_doc_log pm-discovery "wrote docs/discovery.md"   # global heartbeat: this page write -> wiki/log.md

---

Interview-prep mode

Run this when the user wants a hypothesis-driven interview guide to take into a live user call, rather than the full opportunity-mapping flow. The output is a prep deliverable for the human — a compass for the conversation. This mode writes nothing: no wiki page, no opportunity entry, no feedback writeback. (When the user comes back from the call with notes or a transcript, that's /pm-add-feedback — it imports, extracts signal, and updates the wiki. Point them there at the end.)

The goal of an interview is never to pitch. The goal is to collect specific stories from the past that reveal real behavior.

Frameworks used

This mode draws from four recognized approaches:

• Rob Fitzpatrick (The Mom Test): Only ask questions that are honest even if the interviewee wants to please you. Past behavior only, no hypotheticals.
• Teresa Torres (Continuous Discovery Habits): One specific story per interview. Anchor to a real past event, then excavate the timeline.
• Bob Moesta (JTBD Switch Interview): Map the full decision timeline — from first dissatisfaction to current use. Identify the four forces (push, pull, anxiety, inertia).
• Cindy Alvarez (Lean Customer Development): Falsify your critical hypotheses. Know your top 3 questions before the call. End with a forward action.

Prep Phase 1: Set the focus

If you arrived here straight from Map mode, reuse the user definition, jobs, workarounds, and assumptions you already gathered (Phases 2 & 4) — don't re-ask. Otherwise pull prior context and the primary persona through the query primitive (same call shape as Phase 2 above), then ask via AskUserQuestion:

"What are you trying to learn from this interview?

Be specific — name the assumption or behavior you want to understand.

Good examples:

• 'I want to know why PMs at startups feel their standup process is broken'
• 'I want to understand why users drop off after onboarding step 3'
• 'I want to know what workaround people use when they can't do X'

Bad examples (too vague):

• 'What users think of the product'
• 'General feedback'"

If a prior discovery or challenge session surfaced a top-risk assumption, suggest it as the default focus. Let the user confirm or override.

From the focus, extract or infer:

• The specific behavior to anchor the story on (e.g., "the last time they chose what to watch")
• The critical hypotheses to falsify (max 3)
• The stage (pre-product/discovery, feature validation, churn/retention investigation, positioning)

Prep Phase 2: Interviewee profile

Ask via AskUserQuestion:

"Who is the person you're interviewing?

• Job title and company size
• Their relationship to the problem: current user / churned user / prospect / never tried it
• How you found them

If you don't have someone yet, I can write a recruitment message."

If no subject yet: write a 3-sentence recruitment message (LinkedIn or Slack) targeting the ideal profile from the persona / discovery context. Include: who you're looking for, what you want to talk about (problem, not your solution), and a clear ask (30-min call).

Interview type detection: Based on the relationship to the problem, classify the session:

• Current user → use story-based (Torres) + JTBD ongoing use questions
• Churned user / switched away → use JTBD Switch full timeline (Moesta)
• Prospect / never tried → use Lean Customer Dev (Alvarez) + Mom Test
• Buyer / decision-maker → use positioning interview (Dunford framing)

Prep Phase 3: Build the interview guide

Generate a complete, ready-to-use interview guide. The guide is a compass, not a script (Constable) — questions are ordered by criticality, most important hypotheses first.

---

Opening (3–5 min)

Set the frame:

"Thanks for making time. I'm trying to understand your experience with [problem area] — I'm not here to pitch anything, just to learn. I'll ask you about specific situations you've been in, not hypothetical scenarios. Mind if I take notes?"

Warm-up:

"Tell me a bit about your role and what [relevant activity] looks like in a typical week."

---

Story anchor (Torres method)

Pick ONE behavior most likely to reveal the assumption. Anchor to a real past event:

"I'd love to start with a specific situation. Tell me about the last time you [specific behavior]."

• If they generalize ("I usually...") → redirect: "Let's focus on one specific time — the most recent one you can remember. Walk me through what actually happened."
• Excavate the timeline with neutral prompts: "What happened first?" / "What happened next?" / "What made you decide to do that?"
• Never interpret while they're talking. Note, then follow up.

---

Core questions (15–20 min)

Generate 5–7 questions based on the interview type and focus. Apply these rules for every question:

Mom Test rules (Fitzpatrick):

• ✓ Ask about specific past behavior: "Tell me about the last time..."
• ✓ Ask what they've tried: "What else have you tried to solve this?"
• ✓ Ask about implications: "What happens when [problem] occurs?"
• ✗ Never ask: "Would you use X?" / "Do you think X is a good idea?" / "How much would you pay?"
• ✗ Never ask hypothetical future questions

Mandatory questions (always include):

1. Workaround question: "How are you handling [the problem] right now? Walk me through exactly what you do." → Reveals your real competition. If the answer is "nothing," probe harder — someone with a real problem always has a workaround.

2. Implication question: "What happens if you don't solve this? What does it cost you — time, money, stress?" → Separates a real problem from a minor irritant. No real cost = weak signal.

3. Alternative question: "What else have you tried? What did you like or hate about it?" → Reveals the competitive landscape and pricing anchor.

For JTBD Switch sessions (Moesta), follow the 6 stages:

1. First Thought: "When did you first realize something needed to change? What triggered that?"
2. Passive Looking: "At what point did you start casually noticing alternatives?"
3. Active Looking: "When did you start seriously evaluating options?"
4. Deciding: "Walk me through the moment you made the decision."
5. Onboarding: "What was the first thing you did after you started?"
6. Ongoing Use: "How is your situation different now? What can you do that you couldn't before?"

Map the four forces during the session:

• Push (frustration with current situation): listen for "I was frustrated by...", "It wasn't working because..."
• Pull (attraction to new solution): listen for "I heard that...", "I wanted to be able to..."
• Anxiety (fear of switching): listen for "I was worried that...", "I wasn't sure if..."
• Inertia (attachment to old solution): listen for "I was used to...", "We had already..."

Probing techniques (NNG funnel):

• "Can you tell me more about that?"
• "What do you mean by [vague word]?" — never let abstract words (easy, fast, better) pass without unpacking
• "Why does that matter to you?"
• Silence — wait 3–5 seconds before following up. Interviewees fill silence with the most honest answers.
• "You mentioned X — can we go back to that?"
• "Faster than what?" / "Better than how?" (Moesta) — contrast reveals meaning

---

Hypothesis check (Alvarez)

For each of the top 3 critical hypotheses, include one targeted question. Order these by criticality — most important first (Constable: if the call cuts short, you've still tested the most critical hypothesis).

Format:

Hypothesis: [belief]
Question: [specific behavior-based question to test it]
Confirmation signal: [what answer would confirm it]
Refutation signal: [what answer would refute it]

---

Closing (3–5 min)

"Is there anything about [problem area] you expected me to ask that I didn't?" "Who else do you think I should talk to? Could you introduce me?" "What would be most useful for me to send you as a follow-up?"

Forward action (Alvarez): always end with a specific next step — an intro, a follow-up session, or sharing a prototype later.

---

Anti-patterns to avoid

What to avoid	Why
"Would you use X?"	Produces false positives — people say yes to be polite
Pitching before the core questions	Biases every answer that follows
Interpreting aloud while they talk	Shuts down their train of thought
Asking compound questions	Interviewee answers only the easiest part
Accepting vague answers without probing	"It was frustrating" tells you nothing
Asking about hypothetical futures	Behavior prediction is unreliable

---

Prep Phase 4: Hand off

Tell the user:

"Guide ready. Recommended duration: 30–45 min. The questions are ordered by importance — if the call runs short, you've still covered the most critical hypothesis.

When you're done with the call, run /pm-add-feedback with your notes (or your Granola transcript) — it extracts the signal and updates the wiki Feedback page."

This mode ends here. It writes nothing to the wiki.

STATUS: DONE

---

Completion

Tell the user:

• Discovery page written to .nanopm/wiki/docs/discovery.md
• The top assumption by risk score and the cheapest way to test it
• How long each test should take before results are actionable
• "Run tests before building. The goal of discovery is to fail fast on paper, not in code."
• Recommended next: run the tests, then /pm-challenge-me

STATUS: DONE