product-discovery — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited product-discovery (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
"Discovery without delivery = analysis paralysis. Delivery without discovery = feature factory."
This skill covers the Discovery System — continuously discovering which problems matter and which solutions might work. It maintains a living map of customer opportunities and tests solution ideas before committing engineering resources.
Part of: Modern Product Operating Model — a collection of composable product skills.
Related skills: product-strategy, product-architecture, product-delivery, ai-native-product, product-leadership
Use this skill when:
Cadence: Weekly rhythm | Owner: Product Trio (PM + Designer + Tech Lead)
Most teams either:
The Discovery System creates a weekly rhythm that keeps you close to customers and ensures evidence—not opinions—drives decisions.
The Weekly Rhythm (Minimum Viable Discovery)
| Activity | Frequency | Purpose |
|---|---|---|
| Customer interviews | 2-3 per week | Stay connected to real problems |
| Synthesis session | 1 per week | Update opportunity map |
| Assumption test | 1 per week | Validate before building |
Who Does Discovery: The Product Trio
| Role | Contribution |
|---|---|
| Product Manager | Owns outcome, facilitates, synthesizes |
| Product Designer | Owns experience, visualizes, prototypes |
| Tech Lead | Owns feasibility, estimates, identifies constraints |
Principle: The trio does discovery together. If the PM does interviews alone and hands notes to designers, you've already lost 50% of the insight.
0→1 Mode:
Scaling Mode:
After each interview, create a snapshot (not a transcript). Capture the essence, not every word.
Snapshot Format:
INTERVIEW SNAPSHOT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Date: [Date]
Participant: [Role, Company type, Context]
Interviewer(s): [Names]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KEY OPPORTUNITIES (Unmet needs discovered)
• [Opportunity #1]
• [Opportunity #2]
• [Opportunity #3]
KEY QUOTE (In their words)
"[Memorable statement that captures their experience]"
QUICK FACTS
• [Relevant context about their situation]
• [Current workflow or tools]
• [Constraints or requirements]
JOBS TO BE DONE (If surfaced)
• Functional: [Task they're trying to accomplish]
• Emotional: [How they want to feel]
• Social: [How they want to be perceived]
SURPRISES
• [Anything unexpected]
• [Assumptions challenged]
FOLLOW-UPS
• [Questions for next interview]
• [Things to validate]AI Integration for Snapshots:
The OST is your living map connecting outcomes to opportunities to solutions to tests.
Structure:
OUTCOME
(Metric we're trying to move)
│
┌──────────────┼──────────────┐
│ │ │
OPPORTUNITY OPPORTUNITY OPPORTUNITY
(Unmet need) (Unmet need) (Unmet need)
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ │ │ │ │ │
SOLUTION SOLUTION SOLUTION SOLUTION SOLUTION SOLUTION
(Idea) (Idea) (Idea) (Idea) (Idea) (Idea)
│ │
┌──┴──┐ ┌──┴──┐
│ │ │ │
TEST TEST TEST TESTOST Rules:
| Rule | Why |
|---|---|
| One outcome per tree | Don't try to solve everything at once |
| Opportunities are problems, not solutions | "Users struggle to..." not "Add a feature..." |
| Multiple solutions per opportunity | Always explore 3+ before committing |
| Evidence-backed | Each opportunity has interview/data support |
| Living document | Update weekly as you learn |
Good Opportunity Statements:
Bad Opportunity Statements (These are solutions):
Target Opportunity Selection:
Use compare-and-contrast to select focus:
| Opportunity | Pain Severity | Frequency | Strategic Fit | Evidence Strength |
|---|---|---|---|---|
| A | High | Daily | Core | 8 interviews |
| B | Medium | Weekly | Adjacent | 3 interviews |
| C | High | Monthly | Core | 12 interviews |
Principle: Choose ONE target opportunity at a time. Complete focus beats scattered effort.
For every target opportunity, generate at least 3 solution approaches before committing.
The Three Solution Types:
| Type | Description | Example |
|---|---|---|
| The obvious solution | What everyone expects | "Add an onboarding wizard" |
| The 10x harder solution | If effort were no constraint | "AI-powered personalized setup" |
| The non-product solution | Pricing, process, partnership, or service | "White-glove onboarding call" |
Solution Categories:
| Category | When to Consider |
|---|---|
| Product changes | Features, UX improvements |
| Pricing/packaging changes | How value is captured |
| Enablement changes | Documentation, training, support |
| Process changes | How work gets done internally |
| Partnership solutions | Integrate vs. build |
Principle: The best solution to a product problem is often not a product change.
Thin-Slice MVP:
Don't build the whole solution. Build the smallest thing that tests your riskiest assumption.
| Full Solution | Thin Slice |
|---|---|
| "Complete onboarding wizard with 10 steps, progress tracking, and personalization" | "Single welcome screen that asks one question and shows one recommendation" |
| "Full analytics dashboard with customizable widgets" | "One pre-built view showing the top 3 metrics" |
| "AI-powered recommendation engine" | "Rule-based suggestions for top 5 use cases" |
Every solution has assumptions. Find the ones that would kill it if wrong.
Assumption Categories:
| Category | Question |
|---|---|
| Desirability | Will users want this? |
| Viability | Will this work for the business? |
| Feasibility | Can we build this? |
| Usability | Can users figure it out? |
Assumption Test Format:
ASSUMPTION TEST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Assumption: [What we believe is true]
Risk level: [High / Medium / Low]
Test method: [How we'll test]
Success criteria: [What would confirm]
Failure criteria: [What would disprove]
Timebox: [Hours/days, not weeks]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Test Methods (Fastest to Slowest):
| Method | Time | When to Use |
|---|---|---|
| Desk research | 30 min | Does evidence already exist? |
| One-question survey | 1 hour | Quick signal from existing users |
| Fake door test | 1 day | Measure interest before building |
| Concierge test | 1-3 days | Manually deliver the value |
| Wizard of Oz | 1 week | Fake backend, real frontend |
| Prototype test | 1-2 weeks | Clickable prototype with users |
| A/B test | 2-4 weeks | Live code, statistical significance |
Principle: Test in hours and days, not weeks and months. If your test takes a month, you're testing too much at once.
AI Integration for Testing:
Weekly cross-functional meeting that turns discovery into decisions. Prevents discovery theater.
Participants:
Agenda (60 min max):
| Segment | Time | Focus |
|---|---|---|
| New evidence review | 15 min | 2-3 key findings from this week |
| Opportunity prioritization | 20 min | Promote, kill, or park opportunities |
| Solution shaping | 15 min | Review prototype/test results |
| GTM/tech flags | 10 min | Early visibility on constraints |
Council Rules:
0→1 Mode: Skip formal council. Founder + team informal sync.
| Output | Description | Update Cadence |
|---|---|---|
| Opportunity Solution Tree | Living map of outcome → opportunities → solutions | Weekly |
| Interview snapshots | Library of customer evidence | After each interview |
| Test results | What we learned, what we decided | After each test |
| Target opportunity | Current focus area | Weekly review |
| Solution candidates | Prototypes ready for prioritization | Ongoing |
This skill includes templates in the templates/ directory:
interview-snapshot.md — Post-interview capture formatopportunity-solution-tree.md — OST structure and rulesassumption-test.md — Test design and trackingAsk Claude to:
| When you need to... | Use skill |
|---|---|
| Define ICP and strategic context | product-strategy |
| Convert opportunities to bets | product-architecture |
| Plan delivery and measurement | product-delivery |
| Discover for AI products | ai-native-product |
| Scale discovery across teams | product-leadership |
Before concluding discovery on an opportunity:
| Anti-Pattern | Why It Fails | Instead |
|---|---|---|
| Discovery theater | Interviews don't change roadmap | Evidence → decisions |
| AI replaces listening | Miss 40% of insight | AI augments, humans decide |
| Solution-first thinking | Build wrong thing | Opportunity-first |
| Homer Simpson car | Feature bloat from asking "what do you want?" | Ask about problems, not solutions |
| PM does discovery alone | Handoffs kill learning | Trio does discovery together |
| One solution per opportunity | Miss better approaches | Always 3+ options |
| Month-long tests | Too slow to learn | Test in hours/days |
Part of the Modern Product Operating Model by Yannick Maurice
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.