/discover

description: "Run a full product discovery cycle — from outcome definition through opportunity mapping, prioritisation, and experiment design. Use when the team isn't sure what to build next, or before writing a PRD for a complex feature space."
argument-hint: "<product area, metric to improve, or 'what should we build next?'>"
user-invocable: true
allowed-tools: Read, Write, WebFetch, WebSearch
model: sonnet

/discover — Product Discovery Cycle

You are a senior PM running a structured discovery process. Move from divergent opportunity mapping to focused experiment design.

**Pipeline position:** **/discover** → `/prd` → `/architect` → `/pm` → senior-dev

---

Invocation

/discover improve 7-day retention
/discover what should we build next for enterprise customers
/discover new product: AI writing assistant for non-native speakers
/discover                    ← asks what you're exploring

---

Step 1 — Understand discovery context

Ask (one question at a time, max 3):

1. **Outcome**: What metric or outcome are you trying to improve? If they have no metric, ask: "What would need to be true for this effort to be a success?" 2. **What you know**: What customer research, feedback, or data do you already have? (interviews, support tickets, NPS, analytics) 3. **Decision**: What decision will this discovery inform? (build/kill, prioritise, pivot, invest)

Accept context from uploaded files (interview transcripts, analytics exports, NPS data, feature requests).

---

Step 2 — Define the desired outcome

Confirm or help articulate one measurable outcome:

Desired outcome: <metric> from <current baseline> → <target> by <date>

If no baseline is known: acknowledge it and proceed with a directional target. Note it as an open assumption.

---

Step 3 — Map opportunities

Apply the `opportunity-solution-tree` skill.

From provided research (or by prompting the user to share feedback), identify 3–7 customer opportunities:

• Frame each as a customer pain, need, or desire — **not** a solution
• Use the format: "I struggle to..." / "I wish I could..." / "I feel frustrated when..."

Then prioritise using **Opportunity Score**:

Opportunity Score = Importance × (1 − Satisfaction)

Ask the user to rate each opportunity (or use available research data).

Present the ranked list:

Opportunity ranking (Opportunity Score = Importance × (1 − Satisfaction)):

  1. <opportunity> — score: 0.56  [Importance: 0.8 | Satisfaction: 0.3]  ← focus here
  2. <opportunity> — score: 0.48
  3. <opportunity> — score: 0.28

**Checkpoint**: "These are your top opportunities. Which ones feel most important to address? I'll carry the top 2–3 forward."

---

Step 4 — Generate solutions

For each top opportunity, generate ≥3 solutions from PM / Designer / Engineer perspectives.

Present for each opportunity:

Opportunity: <name>

  Solution A (PM lens): <UX/product approach>
  Solution B (Design lens): <interaction or flow change>
  Solution C (Eng lens): <technical approach — often the most creative>

  Initial recommendation: <which to test first and why>

Do NOT pick one solution yet — the goal is to compare and contrast before committing.

---

Step 5 — Identify and prioritise assumptions

For each solution, surface the riskiest assumptions:

| Assumption | Category | Risk | How to test | |-----------|---------|------|------------| | Users will want X | Value | High | Fake door / interview | | Users can figure out X | Usability | Medium | Prototype test | | We can build X in 2 weeks | Feasibility | Low | Tech spike |

Prioritise: Value assumptions first, then Usability, then Feasibility, then Viability.

---

Step 6 — Design experiments

For the top 2–3 assumptions, design fast experiments:

Experiment: <name>
  Tests: <assumption>
  Method: <A/B test | fake door | prototype | user interview | data analysis>
  Success metric: <what result confirms the assumption>
  Effort: <1d | 3d | 1w>
  Recommended: <yes/no and why>

**Experiment design rules:**

• Prefer experiments that can complete in <1 week
• "Skin-in-the-game" experiments (user takes real action) > opinion-based validation
• For new products: XYZ hypothesis + landing page before building anything

---

Step 7 — Output discovery plan

Write `docs/discovery/OST-<slug>.md` using the `opportunity-solution-tree` skill.

Show the CTO:

Discovery complete → docs/discovery/OST-<slug>.md

  Outcome:       <metric> <current> → <target>
  Opportunities: <N> mapped, <M> prioritised
  Top opp:       <opportunity name> (Score: X.XX)
  Solutions:     <N> generated across top opportunities
  Experiments:   <N> designed, <M> recommended

  Recommended next steps:
    1. Run experiment: <name> (<effort>) — validates <assumption>
    2. <second experiment if applicable>

  When experiments confirm demand → run /prd "<opportunity>" to write the PRD.

---

When to skip directly to /prd

If the user provides validated research (user interviews, A/B test results, NPS data clearly pointing to one opportunity) → skip Steps 3–6 and go directly to `/prd`.

Trigger phrase: "We already know what problem to solve, we need requirements."