guhcostan Product Discovery
Help turn product ideas into validated opportunities through structured discovery. Understand the problem deeply before thinking about solutions.
Start by exploring the current product context, then conduct discovery through JTBD mapping, user research, and opportunity assessment. Once discovery is complete, present findings and get approval before moving to PRD.
Anti-Pattern: "This Is Obvious, We Already Know the Problem"
Every product initiative goes through discovery. A login button, a settings page, a minor UX tweak — all of them. "Obvious" features are where unexamined assumptions cause the most wasted engineering effort. The discovery can be short (a few minutes for truly simple features), but you MUST present findings and get approval.
Checklist
You MUST create a task for each of these items and complete them in order:
- Explore current context — Check existing product docs, analytics, user feedback, recent changes, competitive landscape
- Define the desired outcome — What business or user metric are we trying to move? Frame as an outcome, not an output.
- Map Jobs-to-be-Done — What job is the user hiring this product/feature to do? Functional, emotional, and social dimensions.
- Conduct user research — Interview users following The Mom Test principles. Uncover needs, pain points, and desires — don't validate your existing ideas.
- Complete Opportunity Assessment — Answer all 10 SVPG questions
- Validate the problem — Use lightweight validation techniques before committing to building
- Present findings — Problem statement, evidence, opportunity size, key risks
- Save discovery doc — Write to
docs/product-superpowers/discovery/YYYY-MM-DD-<topic>.md - User reviews and approves — Wait for explicit approval before proceeding to PRD
The Process
Step 1: Explore Current Context
Before asking the user anything, gather what already exists:
- Review any existing product docs, PRDs, or discovery docs in the project
- Check analytics data (if available): what are users doing? Where do they drop off?
- Review recent user feedback, support tickets, NPS comments
- Check competitive landscape for this problem space
- Understand the current product architecture and technical constraints
Step 2: Define the Desired Outcome
Reframe the request as an outcome, not an output.
| Instead of (output) | Ask (outcome) |
|---|---|
| "Build a dark mode" | "Are users struggling with eye strain or battery life?" |
| "Add a share button" | "Are users trying to collaborate or spread awareness?" |
| "Build a dashboard" | "What decisions do users need to make with this data?" |
Use the format: "Improve [metric] from [baseline] to [target] by [timeframe]"
Example: "Increase new user activation rate from 40% to 65% by Q3."
Step 3: Map Jobs-to-be-Done
For each user segment, identify the Job-to-be-Done:
Job Statement Format:
When [situation],
I want to [motivation],
so I can [expected outcome].
Map the Forces of Progress for each job:
| Force | Question |
|---|---|
| Push (pain of current state) | What's frustrating about how they do it today? |
| Pull (attraction of new solution) | What makes the new way compelling? |
| Anxiety (worries about new solution) | What concerns do they have about switching? |
| Habit (allegiance to current behavior) | What keeps them using the current approach? |
Job Mapping — Break the job into steps:
Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude
JTBD Interview Questions:
- "Tell me about the last time you [did the activity]?"
- "What was going on in your life that led you to look for a solution?"
- "What did you try before using our product (or a competitor)?"
- "What made you decide to finally switch?"
Step 4: Conduct User Research (The Mom Test)
Talk to users. Follow Rob Fitzpatrick's principles:
- Don't pitch your solution. Ask about their problems and current behavior.
- Talk about their life, not your idea. "Tell me about how you currently handle X."
- Ask about specific past instances, not generic opinions. "When was the last time...?" not "Would you ever...?"
- Listen for commitments, not compliments. "That's interesting" is not validation.
- Avoid premature zoom-in. Don't focus on one solution before understanding the broad problem space.
Research methods to consider:
- User interviews (1:1 conversations)
- Contextual inquiry (observe users in their environment)
- Surveys (for quantitative validation)
- Analytics review (what are users actually doing?)
- Support ticket analysis (what are common pain points?)
Step 5: Opportunity Assessment (SVPG)
Answer all 10 questions:
- Exactly what problem will this solve? (value proposition)
- For whom do we solve that problem? (target market/persona)
- How big is the opportunity? (market size, affected users, revenue potential)
- How will we measure success? (specific metrics and targets)
- What alternatives are out there now? (competitive landscape, substitutes)
- Why are we best suited to pursue this? (our differentiator, unfair advantage)
- Why now? (market timing, urgency, window of opportunity)
- How will we get this to market? (go-to-market strategy, channels)
- What factors are critical to success? (key solution requirements, must-have capabilities)
- Given the above, is it worth pursuing? (go/no-go recommendation)
Step 6: Validate the Problem
Before committing to building, validate using lightweight techniques:
| Technique | What it is | Best for |
|---|---|---|
| Problem interviews | Talk to potential users about the problem (no solution shown) | Understanding if the problem is real |
| Landing page test | Create a page describing the solution, measure interest | Gauging demand before building |
| Wizard of Oz test | Simulate a working product manually behind the scenes | Testing value prop without engineering |
| Concierge MVP | Manually deliver the service to early customers | Learning what users really need |
| Smoke test | "Buy now" button or ad that measures intent | Validating willingness to pay/act |
| Value Proposition Canvas | Map customer jobs/pains/gains to your solution | Systematic problem-solution fit check |
Step 7: Present Findings
Present the discovery summary:
- Problem Statement — One sentence: what problem, for whom, why it matters
- Evidence — What data, interviews, or research supports this is a real problem
- Opportunity Size — How many users affected, revenue impact, strategic importance
- Key Risks — Biggest uncertainties and how to resolve them
- Recommendation — Pursue / Investigate Further / Deprioritize
Step 8: Save Discovery Document
Write the validated discovery to docs/product-superpowers/discovery/YYYY-MM-DD-<topic>.md
Document structure:
# [Topic] — Product Discovery
**Date:** YYYY-MM-DD
**Status:** Approved / Needs More Research / Deprioritized
## Problem Statement
...
## Desired Outcome
...
## Jobs-to-be-Done
...
## Research Findings
...
## Opportunity Assessment
...
## Validation Results
...
## Recommendation
...
## Open Questions
...
Step 9: User Review Gate
After saving the discovery doc:
"Discovery complete and saved to
docs/product-superpowers/discovery/<filename>.md. Please review the findings and let me know if you approve moving to PRD, need more research, or want to deprioritize."
Wait for the user's response. If they request more research, do it. If they approve, move to PRD. If they deprioritize, archive.
Key Principles
- Problem before solution — Don't think about what to build until you understand what to solve
- Evidence over intuition — Every claim should be backed by data, research, or cited examples
- Outcome over output — Frame everything as a metric to move, not a feature to ship
- User voice over internal opinion — Your opinion matters less than what users actually do and say
- Lightweight is allowed — For simple features, discovery can be brief. But it must still be done.
Red Flags — STOP and Return to Discovery
- Writing PRD before discovery is complete
- Solution-first thinking ("we should build X" without understanding the problem)
- Confirmation bias (only seeking evidence that supports your idea)
- Skipping user research because "we already know"
- Over-relying on one method (only analytics, only surveys, etc.)
- Not including engineers or designers in discovery
- Treating discovery as a phase with a fixed end date (it's continuous)
Transition to PRD
Once discovery is approved, invoke the writing-prd skill to create the Product Requirements Document. Do NOT invoke any other skill.
Key References
- Marty Cagan, "Inspired" and "Empowered" (SVPG)
- Teresa Torres, "Continuous Discovery Habits"
- Rob Fitzpatrick, "The Mom Test"
- Clayton Christensen, "Competing Against Luck" (JTBD)
- Strategyzer, "Value Proposition Design"