Build products customers actually want. Apply Marty Cagan's Silicon Valley-tested framework to discover solutions that are valuable, usable, feasible, and viable.

• New product development when validating what to build
• Feature prioritization to ensure you're solving real problems
• Pivot decisions when current direction isn't working
• Team alignment on what problems to solve
• Risk reduction before committing development resources
• Continuous discovery to maintain product-market fit

1. Frames the four risks - Value, usability, feasibility, viability
2. Distinguishes discovery from delivery - Different mindsets, different processes
3. Teaches opportunity assessment - Which problems to solve
4. Develops prototyping skills - Test ideas before building
5. Guides customer research - Learn what customers need (not want)
6. Structures continuous discovery - Ongoing learning, not one-time research

• Does this solve a real problem?
• Is the problem painful enough to pay/switch for?
• Will users actually adopt this?

• Customer interviews
• Demand testing
• Fake door tests
• Concierge MVP

• Is it intuitive?
• Can users accomplish their goals?
• What's the learning curve?

• Prototype testing
• Usability studies
• Wizard of Oz tests
• A/B tests on UX

• Do we have the technology?
• Can we do it in reasonable time?
• What are the technical dependencies?

• Technical spike
• Proof of concept
• Architecture review
• Build vs. buy analysis

• Does it fit our strategy?
• Can we support/maintain it?
• Is it legal/compliant?
• Does the business model work?

• Business case
• Stakeholder review
• Compliance review
• Financial modeling

---

• Embrace uncertainty
• Test assumptions
• Fail fast and cheap
• Learn over deliver

• Customer interviews
• Prototyping
• Experiments
• Opportunity assessment

• Validated problems
• Tested solutions
• Confidence to build
• Clear success metrics

• Reduce uncertainty
• Execute efficiently
• Ship quality
• Hit timelines

• Engineering
• QA
• Launch prep
• Documentation

• Working software
• Happy customers
• Business impact
• Technical quality

• Build features no one wants
• Waste engineering resources
• Miss market opportunities
• Frustrated team, frustrated customers

---

• High frequency + High intensity = Strong opportunity
• Low frequency OR Low intensity = Weak opportunity

• Frequency: [1-5]
• Intensity: [1-5]
• Willingness to pay/switch: [1-5]
• Market size: [1-5] Problem Score: [Average]

• Technical feasibility: [1-5]
• Strategic fit: [1-5]
• Competitive advantage: [1-5] Solution Score: [Average]

• Urgency: [1-5]
• Resource availability: [1-5] Timing Score: [Average]

1. Context: Understand their current situation
2. Problem: Explore the pain points
3. Impact: How does it affect them?
4. Current solutions: What do they do today?
5. Ideal state: What would "solved" look like?

• Ask about past behavior, not future intentions
• Don't pitch, just listen
• Follow the emotion
• Get specific stories

• "Walk me through the last time this happened..."
• "What did you do? What happened next?"
• "Why was that a problem?"
• "What would have made it better?"

• Fake door: Button for feature that doesn't exist
• Smoke test: Landing page before building
• Concierge: Manual delivery of automated value
• A/B test: Compare variations with real users

1. Hypothesis: "We believe [X]"
2. Test: "We will test by [Y]"
3. Metric: "We will measure [Z]"
4. Success: "[Number] indicates we should proceed"

            [Desired Outcome]
                   |
    ┌──────────────┼──────────────┐
    |              |              |
[Opportunity 1] [Opportunity 2] [Opportunity 3]
    |              |              |
  ┌─┴─┐          ┌─┴─┐          ┌─┴─┐
  |   |          |   |          |   |
[S1] [S2]      [S1] [S2]      [S1] [S2]

• Start with business outcome
• Break into opportunities (problems to solve)
• Brainstorm solutions for each opportunity
• Test solutions, not opportunities

---

• Review last week's learnings
• Prioritize this week's questions
• Schedule interviews/tests

• Customer interviews (2-3 per week minimum)
• Prototype testing
• Data analysis
• Experiment monitoring

• Consolidate learnings
• Update opportunity assessment
• Share with delivery team
• Plan next week

• Minimum: 2-3 customer conversations/week
• Mix: Prospects, users, churned customers

• List key assumptions
• Design tests for riskiest ones
• Document learnings

• Always have 2-3 experiments running
• Quick iterations over perfect tests

• Engineering in discovery
• Design in customer calls
• PM facilitates, doesn't dictate

• Doing research but not changing decisions
• Fix: Tie discovery directly to roadmap decisions

• Quarterly research sprints instead of continuous
• Fix: Small, frequent over large, infrequent

• Only seeking confirmation
• Fix: Actively try to disprove hypotheses

---

"We're thinking of adding a calendar integration to our project management tool. How do I validate this before we build it?"

1. "Walk me through how you schedule work for your team right now."
2. "What happens when deadlines slip? How do you find out?"
3. "What role does your calendar play in project management?"
4. "What's frustrating about keeping projects and calendars in sync?"
5. "Show me the last time you missed something because of calendar/project disconnect."

• Is there a real pain? How intense?
• What workarounds do they use today?
• Is this a "nice to have" or "need to have"?

1. Add "Calendar Sync (Coming Soon)" button to settings
2. When clicked: "Thanks for your interest! Join the waitlist."
3. Track: Click rate, waitlist conversions

• 5% of MAU click the button = Strong signal

• 2-5% = Moderate signal
• <2% = Weak signal

• How many users mention "calendar" in support tickets?
• What integrations do users currently connect?
• Are users with calendar tools more or less engaged?

1. Calendar sync setup flow
2. How synced events appear
3. Conflict resolution

• Can they set it up without help?
• Does it match their mental model?
• What's confusing?

1. Manually sync their calendar items to projects
2. Send them a summary email daily
3. Interview after 1 week: Was this valuable?

• Week 1: Interviews → Problem understanding
• Week 2: Fake door + data → Demand validation
• Week 3: Prototype → Solution validation
• Week 4: Synthesize → Build decision

"I'm a PM at a B2B SaaS startup. We don't do any formal discovery—we just build what customers ask for or what the CEO wants. How do I start continuous discovery?"

• Redesign your entire process
• Stop all current development
• Hire a research team

• Add one discovery habit per week
• Start with what you control
• Show value quickly

• 1 customer who recently churned or downgraded
• 1 customer who recently upgraded or is highly engaged

• What problem were they trying to solve?
• What's working? What's not?
• What surprised me?

• Survey in-app about a proposed feature
• Fake door for feature idea
• A/B test on onboarding

• "We talked to 8 customers. Here's what we learned."
• "We ran one experiment. It told us [X]."
• "This prevented us from building [feature] that data shows customers don't actually need."

1. Formalize interview cadence: 2-3/week team standard
2. Create opportunity backlog: Problems we might solve
3. Link to roadmap: Discovery informs what we build
4. Involve engineering: Engineers in customer calls

"We have three potential features to build: (A) AI-powered suggestions, (B) Team collaboration improvements, (C) Mobile app. How do I assess which to prioritize?"

• Value: Will suggestions be good enough to use?
• Feasibility: Do we have ML talent?
• Viability: Training data requirements, cost

• Value: Which specific collaboration features matter?
• Usability: Team features can get complex quickly

• Viability: Ongoing maintenance cost
• Feasibility: Native vs. cross-platform decisions

1. Prioritize Team Collaboration
   • Highest problem intensity
   • Clear strategic fit
   • Feasible to build
2. Park AI Suggestions for now
   • Validate value risk first
   • Consider: What specific suggestions would be valuable?
   • Test with simple rules before ML
3. Deprioritize Mobile App
   • High effort, limited reach
   • Consider: Progressive web app as interim?
   • Revisit when team collaboration is strong

• Run 5 interviews focused on team collaboration pain points
• Identify top 3 specific collaboration problems
• Prototype and test before committing to full build

• customer interviews
• data analyses
• prototype tests
• experiments

• Metric 1:
• Metric 2:
• Metric 3:

---

• Structuring persuasive content
• Applying copywriting frameworks
• Creating draft variations
• Analyzing competitor approaches

• Guarantee conversion rates
• Replace brand voice development
• Know your specific audience
• Make final approval decisions

• Cagan, Marty. "Inspired: How to Create Tech Products Customers Love" (2018)
• Cagan, Marty & Jones, Chris. "Empowered" (2020)
• Torres, Teresa. "Continuous Discovery Habits" (2021)
• Silicon Valley Product Group (SVPG) resources
• Intercom on Product Management

• customer-discovery - Steve Blank's broader framework
• mom-test - Customer interview techniques
• lean-canvas - Business model validation
• shape-up - Basecamp's build methodology
• design-sprint - Google Ventures sprint

• Mode: cyborg

name: product-discovery
category: product
subcategory: methodology
version: 1.0
author: MKTG Skills
source_expert: Marty Cagan
source_work: Inspired, Empowered
difficulty: intermediate
estimated_value: $10,000+ product consulting engagement
tags: [product, discovery, validation, PM, Cagan, SVPG, risk, prototyping]
created: 2026-01-25
updated: 2026-01-25