customer-discovery
Systematically validate your business hypotheses before building anything. Master Steve Blank's Customer Development methodology that became the foundation of Lean Startup and YC's approach. Use when: **Starting a new venture** to avoid building something nobody wants; **Before writing a line of code** to validate problem-solution fit; **Pivoting decisions** to systematically test new directions; **Early-stage fundraising** to prove market validation; **Product roadmap planning** to prioritiz...
What this skill does
# Customer Discovery > Systematically validate your business hypotheses before building anything. Master Steve Blank's Customer Development methodology that became the foundation of Lean Startup and YC's approach. ## When to Use This Skill - **Starting a new venture** to avoid building something nobody wants - **Before writing a line of code** to validate problem-solution fit - **Pivoting decisions** to systematically test new directions - **Early-stage fundraising** to prove market validation - **Product roadmap planning** to prioritize based on validated customer needs - **Entering new markets** to understand unfamiliar customer segments ## Methodology Foundation | Aspect | Details | |--------|---------| | **Source** | Steve Blank - "The Four Steps to the Epiphany" (2005) | | **Core Principle** | "No business plan survives first contact with customers. Get out of the building." | | **Why This Matters** | Startups fail because they build products nobody wants. Customer Discovery replaces guessing with systematic learning before you run out of money. | ## What Claude Does vs What You Decide | Claude Does | You Decide | |-------------|------------| | Structures content frameworks | Final messaging | | Suggests persuasion techniques | Brand voice | | Creates draft variations | Version selection | | Identifies optimization opportunities | Publication timing | | Analyzes competitor approaches | Strategic direction | ## What This Skill Does 1. **Documents business hypotheses** - Turns assumptions into testable statements 2. **Designs validation experiments** - Creates tests that can prove you wrong 3. **Structures customer conversations** - Gets real insights, not false positives 4. **Evaluates problem-solution fit** - Determines if you should proceed, pivot, or stop 5. **Creates learning roadmap** - Prioritizes what to validate first 6. **Tracks validation progress** - Maintains evidence-based decision making ## How to Use ### Start Customer Discovery for a New Idea ``` I'm starting customer discovery for [business idea]. Help me document my hypotheses and design validation experiments. Use Steve Blank's Customer Development methodology. ``` ### Evaluate Customer Discovery Progress ``` Here's what I've learned from [X] customer interviews: [summary] Evaluate my progress against Customer Discovery criteria. Should I proceed, pivot, or go back to more interviews? ``` ### Design a Validation Experiment ``` I need to validate this hypothesis: [hypothesis] Design a Customer Discovery experiment to test it. What would prove it true? What would prove it false? ``` ## Instructions When helping with Customer Discovery, follow Steve Blank's systematic approach: ### Step 1: Document Your Business Model Hypotheses ``` ## Business Model Canvas Hypotheses Before talking to customers, document what you BELIEVE to be true. These are GUESSES until validated. ### Customer Hypotheses | # | Hypothesis | Confidence | Evidence | |---|------------|------------|----------| | C1 | Our target customer is [WHO] | Low/Med/High | [None yet] | | C2 | They have this problem: [WHAT] | Low/Med/High | [None yet] | | C3 | The problem is severe because [WHY] | Low/Med/High | [None yet] | | C4 | They currently solve it by [HOW] | Low/Med/High | [None yet] | ### Value Proposition Hypotheses | # | Hypothesis | Confidence | Evidence | |---|------------|------------|----------| | V1 | Our solution provides [BENEFIT] | Low/Med/High | [None yet] | | V2 | Customers care about [FEATURE/OUTCOME] | Low/Med/High | [None yet] | | V3 | We're differentiated by [UNIQUE VALUE] | Low/Med/High | [None yet] | ### Channel Hypotheses | # | Hypothesis | Confidence | Evidence | |---|------------|------------|----------| | H1 | We can reach customers through [CHANNEL] | Low/Med/High | [None yet] | | H2 | Customer acquisition will cost [ESTIMATE] | Low/Med/High | [None yet] | ### Revenue Hypotheses | # | Hypothesis | Confidence | Evidence | |---|------------|------------|----------| | R1 | Customers will pay [PRICE] | Low/Med/High | [None yet] | | R2 | Revenue model: [TYPE] | Low/Med/High | [None yet] | | R3 | Lifetime value: [ESTIMATE] | Low/Med/High | [None yet] | ``` **Critical Rule:** You don't have a business until these hypotheses are validated with real evidence from real customers. --- ### Step 2: Prioritize What to Validate First ``` ## Hypothesis Prioritization Matrix Prioritize by RISK and IMPACT: | Hypothesis | If WRONG, Impact | Current Confidence | Priority | |------------|------------------|-------------------|----------| | [H1] | Fatal/Major/Minor | Low/Med/High | P1/P2/P3 | | [H2] | Fatal/Major/Minor | Low/Med/High | P1/P2/P3 | ### Priority Rules: - P1: Fatal if wrong + Low confidence → Validate FIRST - P2: Major if wrong + Low/Med confidence → Validate SOON - P3: Minor if wrong OR High confidence → Validate LATER ### Your P1 Hypotheses (Validate These First): 1. ________________________________ 2. ________________________________ 3. ________________________________ These are your "leap of faith" assumptions. ``` --- ### Step 3: Design Validation Experiments ``` ## Experiment Design Template ### Hypothesis Being Tested: "We believe [CUSTOMER SEGMENT] has [PROBLEM] and would [BEHAVIOR]." ### Experiment Type: - [ ] Customer Interviews (Problem Discovery) - [ ] Solution Interviews (Solution Validation) - [ ] Landing Page Test (Demand Validation) - [ ] Concierge MVP (Solution Validation) - [ ] Smoke Test (Demand Validation) ### Success Criteria: **Validated if:** [Specific, measurable outcome] **Invalidated if:** [Specific, measurable outcome] Example: - Validated: 8+ of 10 customers describe this exact problem unprompted - Invalidated: Fewer than 5 of 10 mention this problem ### Sample Size: - Minimum: [Number] customers - Target segment: [Description] ### Data to Collect: 1. 2. 3. ### Timeline: - Start: [Date] - End: [Date] - Go/No-Go Decision: [Date] ``` --- ### Step 4: Conduct Customer Discovery Interviews ``` ## Customer Discovery Interview Framework ### PHASE 1: Problem Discovery (First 5-10 interviews) **Goal:** Understand the problem space, NOT pitch solutions **Interview Structure:** 1. **Context** (5 min): Their role, background, day-to-day 2. **Problem Exploration** (15 min): Deep dive into the problem area 3. **Existing Solutions** (5 min): What they use today 4. **Impact** (5 min): How the problem affects them 5. **Wrap-up** (5 min): Referrals, next steps **Key Questions:** - "Tell me about your biggest challenge with [area]..." - "Walk me through the last time you dealt with [problem]..." - "What solutions have you tried? What worked/didn't work?" - "How much time/money does this cost you?" - "If this magically disappeared, what would change?" **DO NOT:** - Pitch your solution - Ask leading questions - Talk more than 30% of the time - Ask "would you use/pay for..." ### PHASE 2: Solution Discovery (Next 5-10 interviews) **Goal:** Test if your solution addresses validated problems **Only proceed to Phase 2 if:** - [ ] You've talked to 10+ potential customers - [ ] Clear problem patterns emerged - [ ] Problems are severe and frequent enough - [ ] Customers are actively seeking solutions **Solution Interview Structure:** 1. **Recap** (3 min): Confirm the problem you heard 2. **Solution Demo** (10 min): Show concept/prototype 3. **Reaction** (10 min): Their honest feedback 4. **Commitment** (5 min): Would they try/buy/refer? **Key Questions:** - "Does this solve the problem you described?" - "What's missing?" - "What would you pay for this?" - "Would you be willing to pilot this?" - "Who else should see this?" ``` --- ### Step 5: Evaluate Results and Decide ``` ## Customer Discovery Scorecard ### Problem Validation | Criteria | Threshold | Your Result | Pass? | |----------|-----------|-------------|-------| | # of interviews completed | 10+ | | Y/N | | % who confirmed the problem unprompted | 70%+ | | Y/N | | Problem severity (1-10
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.