Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
majiayu000 avatar

Product Discovery

majiayu000/claude-arsenal

  • 353 installs
  • 253 repo stars
  • Updated August 4, 2026
  • majiayu000/claude-arsenal

product-discovery is a Claude Code skill that runs early product discovery to clarify problems, users, hypotheses, and opportunity areas for developers before committing to scope, prototypes, or engineering work.

About

product-discovery is a skill from majiayu000/claude-arsenal that structures upfront product exploration inside agent sessions. It helps teams articulate the core problem, identify target users, draft testable hypotheses, and map opportunity areas before writing specs or code. Developers invoke it when a feature idea lacks validated user pain, when multiple problem framings compete, or when engineering starts too early without discovery artifacts. The skill produces discovery outputs—problem statements, user segments, hypothesis lists, and opportunity maps—that inform later validate-phase prototyping and build-phase scoping. Use product-discovery at project kickoff, greenfield SaaS ideation, or when stakeholders disagree on what problem is worth solving.

  • Problem framing workshops
  • User and market hypothesis lists
  • Opportunity prioritization
  • Assumption mapping
  • Discovery brief outputs

Product Discovery by the numbers

  • 353 all-time installs (skills.sh)
  • Ranked #832 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/majiayu000/claude-arsenal --skill product-discovery

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs353
repo stars★ 253
Last updatedAugust 4, 2026
Repositorymajiayu000/claude-arsenal ↗

How do you run early product discovery before coding?

Run early product discovery to clarify problems, users, hypotheses, and opportunity areas before committing to scope, prototypes, or engineering work.

Who is it for?

Developers or tech leads at project kickoff who need structured discovery before prototypes, specs, or sprint commitments.

Skip if: Mature products with validated requirements where the task is purely implementation or bug fixing.

When should I use this skill?

The user proposes a new product or feature without validated problems, users, or hypotheses and discovery must precede engineering.

What you get

Problem statements, user segment definitions, testable hypotheses, and prioritized opportunity area maps.

Files

SKILL.mdMarkdownGitHub ↗

Product Discovery

Core Principles

  • Continuous Discovery — Weekly user conversations, not episodic research
  • Outcome-Driven — Start with outcomes to achieve, not solutions to build
  • Assumption Testing — Validate risky assumptions before committing resources
  • Co-Creation — Build with customers, not just for them
  • Data-Driven — Use evidence over intuition and stakeholder opinions
  • Problem-First — Deeply understand the problem space before ideating solutions

---

Hard Rules (Must Follow)

These rules are mandatory. Violating them means the skill is not working correctly.

No Solution-First Thinking

Never start with a solution. Always define the problem and outcome first.

❌ FORBIDDEN:
"We should build a search bar for the product page"
"Let's add AI recommendations"
"Users need a mobile app"

✅ REQUIRED:
"Problem: Users can't find products (40% exit rate on catalog)
Outcome: Reduce exit rate to 20%
Possible solutions:
1. Search bar with filters
2. AI-powered recommendations
3. Better category navigation
4. Visual product browsing"

Evidence-Based Decisions

Never assume user needs without evidence from real user research.

❌ FORBIDDEN:
- "Users probably want X" (assumption without data)
- "Our competitor has X, so we need it too" (copycat without validation)
- "The CEO thinks we should build X" (HiPPO without evidence)
- "It's obvious users need X" (intuition without validation)

✅ REQUIRED:
- "5 out of 8 interviewed users mentioned X as a pain point"
- "Analytics show 60% of users abandon at step 3"
- "Prototype test: 7/10 users completed task successfully"
- "Survey (n=500): 45% rated feature as 'must have'"

Minimum Interview Threshold

Never validate a problem with fewer than 5 user interviews per segment.

❌ FORBIDDEN:
- "We talked to 2 users and they loved the idea"
- "One customer requested this feature"
- "Based on a quick chat with sales..."

✅ REQUIRED:
| Segment | Interviews | Key Finding |
|---------|------------|-------------|
| Power Users | 6 | 5/6 struggle with X |
| New Users | 5 | 4/5 drop off at onboarding |
| Churned | 5 | 3/5 cited missing feature Y |

Minimum per segment: 5 interviews
Confidence increases with more interviews

Falsifiable Assumptions

Every assumption must be testable and falsifiable with clear success criteria.

❌ FORBIDDEN:
- "Users will like the new design" (not falsifiable)
- "This will improve engagement" (no success criteria)
- "The feature will be useful" (vague)

✅ REQUIRED:
| Assumption | Test | Success Criteria | Result |
|------------|------|------------------|--------|
| Users will complete onboarding in new flow | Prototype test with 10 users | >70% completion | TBD |
| Users prefer visual search | A/B test | >10% lift in conversions | TBD |
| Price point is acceptable | Landing page test | >3% conversion | TBD |

---

Quick Reference

When to Use What

ScenarioFramework/ToolOutput
Validate product ideaProduct Opportunity AssessmentGo/no-go decision
Size market opportunityTAM/SAM/SOMMarket size estimates
Understand user needsUser Research (interviews, surveys)User insights, pain points
Analyze competitionCompetitive AnalysisCompetitive landscape map
Discover user motivationsJobs-to-be-Done (JTBD)Job stories, outcomes
Prioritize featuresKano ModelFeature categorization
Define value propositionValue Proposition CanvasValue prop statement
Test product conceptLean Startup / MVPValidated learnings
Map opportunitiesOpportunity Solution TreePrioritized opportunities

---

Continuous Discovery Habits

The Product Trio

Discovery is led by three roles working together weekly:

Product Manager → Defines outcomes, owns roadmap
Designer        → Explores solutions, tests usability
Engineer        → Assesses feasibility, proposes technical solutions

Weekly Activities

## 1. Customer Interviews (Weekly)
- Schedule 3-5 interviews per week minimum
- Mix of current users, churned users, prospects
- Focus on understanding problems, not pitching solutions
- Record and share insights with team

## 2. Assumption Testing (Weekly)
- Identify riskiest assumptions about solutions
- Design quick tests (prototypes, landing pages, fake doors)
- Run experiments with real users
- Measure results against success criteria

## 3. Opportunity Mapping (Ongoing)
- Build opportunity solution tree
- Map customer needs to potential solutions
- Prioritize based on impact and feasibility
- Update as you learn

Discovery vs Delivery

Discovery (What to Build)          Delivery (How to Build It)
├─ Customer interviews             ├─ Sprint planning
├─ Prototype testing               ├─ Development
├─ Assumption validation           ├─ QA testing
├─ Market research                 ├─ Deployment
└─ Opportunity assessment          └─ Post-launch monitoring

Key difference: Discovery reduces risk BEFORE committing to build

---

Product Opportunity Assessment

Marty Cagan's 10 Questions

Before starting any product initiative, answer these questions:

## 1. Problem Definition
**What problem are we solving?**
- Be specific and measurable
- Validate it's a real problem (not assumed)

## 2. Target Market
**For whom are we solving this problem?**
- Define specific user segments
- Size the addressable market (TAM/SAM/SOM)

## 3. Opportunity Size
**How big is the opportunity?**
- Revenue potential
- User growth potential
- Strategic value

## 4. Success Metrics
**How will we measure success?**
- Leading indicators (usage, engagement)
- Lagging indicators (revenue, retention)
- Define targets upfront

## 5. Alternative Solutions
**What alternatives exist today?**
- Direct competitors
- Indirect solutions
- Current user workarounds

## 6. Our Advantage
**Why are we best suited to solve this?**
- Unique capabilities
- Market position
- Technical advantages

## 7. Strategic Fit
**Why now? Why us?**
- Market timing
- Strategic alignment
- Resource availability

## 8. Dependencies
**What do we need to succeed?**
- Technical dependencies
- Partnership requirements
- Regulatory considerations

## 9. Risks
**What could go wrong?**
- Market risk (will anyone want it?)
- Execution risk (can we build it?)
- Monetization risk (will they pay?)

## 10. Cost of Delay
**What happens if we don't build this?**
- Competitive disadvantage
- Lost revenue
- Market opportunity window

Value vs Effort Framework

Quick prioritization of opportunities:

High Value, Low Effort  → Do First (Quick Wins)
High Value, High Effort → Plan Strategically (Big Bets)
Low Value, Low Effort   → Do Later (Fill Gaps)
Low Value, High Effort  → Don't Do (Money Pit)

---

Discovery Methods

When to Use What Method

## Generative Research (What problems exist?)
Use when: Starting new product area, exploring unknown space
Methods:
- Ethnographic field studies
- Contextual inquiry
- Diary studies
- Open-ended interviews

## Evaluative Research (Does our solution work?)
Use when: Testing specific solutions, validating designs
Methods:
- Usability testing
- Prototype testing
- A/B testing
- Concept testing

## Quantitative Research (How much? How many?)
Use when: Need statistical validation, measuring impact
Methods:
- Surveys
- Analytics analysis
- A/B experiments
- Market sizing

## Qualitative Research (Why? How?)
Use when: Understanding motivations, uncovering insights
Methods:
- User interviews
- Focus groups
- Customer advisory boards
- User observation

Interview Best Practices

## Preparation
- Define research goals and hypotheses
- Create interview guide (but stay flexible)
- Recruit right participants (6-8 per segment)
- Schedule 45-60 min sessions

## During Interview
✓ Ask open-ended questions ("Tell me about...")
✓ Follow up with "Why?" 5 times to get to root cause
✓ Listen more than talk (80/20 rule)
✓ Ask about past behavior, not future hypotheticals
✓ Look for workarounds and pain points
✓ Record and take notes

✗ Don't ask leading questions
✗ Don't pitch your solution
✗ Don't ask "Would you use X?" (people lie)
✗ Don't multi-task while interviewing

## Example Questions
- "Walk me through the last time you [did task]"
- "What's most frustrating about [current solution]?"
- "How are you solving this problem today?"
- "What would make [task] easier for you?"
- "Tell me more about that..."

Survey Best Practices

## When to Survey
✓ Validate findings from qualitative research
✓ Measure satisfaction or sentiment at scale
✓ Prioritize features (Kano surveys)
✓ Segment users by behavior/needs

## Survey Design
- Keep it short (<10 min to complete)
- One question per screen on mobile
- Mix question types (multiple choice, scale, open-ended)
- Avoid leading or biased questions
- Test survey with 5 people before sending

## Question Types
- Multiple choice → Segmentation, categorization
- Likert scale (1-5) → Satisfaction, importance
- Open-ended → Qualitative insights
- Ranking → Prioritization
- NPS (0-10) → Loyalty measurement

## Distribution
- In-app surveys (high response, biased to engaged users)
- Email surveys (broader reach, lower response)
- Incentivize thoughtful responses ($10 gift card, early access)
- Follow up with interviews for interesting responses

---

2025 Trends in Product Discovery

AI-Powered Research

## AI Tools for Discovery
- **Insight synthesis** — AI analyzes interview transcripts, identifies patterns
- **Synthetic personas** — AI-generated user proxies for rapid testing
- **Market intelligence** — AI tracks competitor moves, pricing changes
- **Survey analysis** — Automated sentiment analysis, theme extraction
- **Trend detection** — AI identifies emerging market trends early

## Examples
- Crayon → Competitive intelligence automation
- Glimpse → Trend detection from web data
- Delve AI → Automated persona creation
- Attest → AI-powered survey insights
- Quantilope → Machine learning research automation

## Best Practices
✓ Use AI to scale research, not replace human insight
✓ Validate AI findings with real user conversations
✓ Combine AI analysis with qualitative depth
✗ Don't rely solely on synthetic users
✗ Don't skip talking to real customers

Continuous Discovery at Scale

## Modern Approach
- Discovery is embedded in every sprint, not a phase
- Weekly user touchpoints (interviews, tests, feedback)
- Rapid experimentation (dozens of tests running)
- Fast pivots based on evidence (days, not months)

## Team Structure
- Product trios own discovery for their area
- Centralized research team supports (tools, methods)
- Customer success shares feedback loop
- Data analysts provide quantitative insights

## Cadence
- Weekly: Customer interviews, prototype tests
- Bi-weekly: Opportunity review, assumption validation
- Monthly: Market analysis, competitive review
- Quarterly: Strategic discovery (new markets, big bets)

---

Opportunity Solution Tree

What It Is

Visual framework for mapping the path from outcome to solution:

        OUTCOME (Business goal)
             |
    ┌────────┴────────┐
    │                 │
OPPORTUNITY 1    OPPORTUNITY 2
    │                 │
    ├─ Solution A     ├─ Solution C
    ├─ Solution B     └─ Solution D
    └─ Solution C

How to Build One

## Step 1: Define Outcome
Start with measurable business outcome
Example: "Increase Day 30 retention from 20% to 30%"

## Step 2: Map Opportunities
Discover customer needs/pain points through research
Example: "Users don't understand core features"

## Step 3: Generate Solutions
For each opportunity, brainstorm multiple solutions
Example:
- Better onboarding tutorial
- In-app tooltips
- Interactive product tour

## Step 4: Test Assumptions
For each solution, identify riskiest assumption and test
Example: "Users will complete a 5-step tutorial"
Test: Build simple prototype, test with 10 users

## Step 5: Compare Solutions
Use evidence to choose best path forward
Build what tests validate, discard what fails

Benefits

✓ Visualizes multiple paths to outcome
✓ Prevents jumping to first solution
✓ Encourages broad exploration before narrowing
✓ Documents why decisions were made
✓ Keeps team aligned on priorities

---

Extended Reference

Detailed material starting at ## Integrating Discovery with Delivery has been moved to `reference/extended.md` to keep this skill concise. Load that reference when the task requires the moved examples, command catalogs, checklists, platform details, or implementation templates.

Related skills

mattpocockGrill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kmattpocockGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196kopen.feishu.cnLark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kopen.feishu.cnLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kopen.feishu.cnLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kopen.feishu.cnLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493k

How it compares

Pick product-discovery for early problem and user framing; pick a prototype skill when hypotheses exist and the next step is building a clickable validation demo.

FAQ

What outputs does product-discovery produce?

product-discovery produces clarified problem statements, target user definitions, testable hypotheses, and opportunity area maps that inform scope, prototyping, and later engineering decisions.

When should teams invoke product-discovery?

Teams should invoke product-discovery before committing to prototypes or engineering when problems, users, and hypotheses are unclear or stakeholders disagree on what to build.

Productivity & Planningpmworkflow
Browse by category
AI & AgentsFrontend & DesignBackend & DataDev ToolsAutomationTesting & ReviewSecurityMonitoring & CloudDocs & Planning
Design & frontend
Design systemsAnimation & motionAccessibility (a11y)CSS & TailwindUI designUXDesign to codeshadcn/uiLanding pagesBest design skills
Most searched skills
find-skillscavemanfrontend-designbrainstormingsystematic-debuggingstop-slopemil-design-engui-ux-pro-maxkarpathy-guidelinesweb-design-guidelinesreact-best-practicesgrill-meimprovemicrosoft-foundryagent-browser
Browse all listings
All agent skillsAll MCP serversAll marketplacesAll plugins

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.