discovery-interviews-surveys
$
npx mdskill add lyndonkl/claude/discovery-interviews-surveysDesign unbiased interview guides and surveys to validate product assumptions.
- Uncover unmet needs, workflows, and pain points through structured research.
- Avoids leading questions, confirmation bias, and selection bias in data.
- Selects methods based on objectives, participants, and available resources.
- Delivers actionable insights on hypotheses, JTBD, and market fit.
SKILL.md
.github/skills/discovery-interviews-surveysView on GitHub ↗
--- name: discovery-interviews-surveys description: Designs structured interview guides, survey instruments, and JTBD probes to learn from users while avoiding common research biases (leading questions, confirmation bias, selection bias). Use when validating product assumptions before building, discovering unmet user needs, understanding customer problems and workflows, testing concepts or positioning, researching target markets, identifying jobs-to-be-done and hiring triggers, or uncovering pain points and workarounds. --- # Discovery Interviews & Surveys ## Table of Contents - [Workflow](#workflow) - [Common Patterns](#common-patterns) - [Guardrails](#guardrails) - [Quick Reference](#quick-reference) ## Workflow Copy this checklist and track your progress: ``` Discovery Research Progress: - [ ] Step 1: Define research objectives and hypotheses - [ ] Step 2: Identify target participants - [ ] Step 3: Choose research method (interviews, surveys, or both) - [ ] Step 4: Design research instruments - [ ] Step 5: Conduct research and collect data - [ ] Step 6: Analyze findings and extract insights ``` **Step 1: Define research objectives** Specify what you're trying to learn, key hypotheses to test, success criteria for research, and decision to be informed. See [Common Patterns](#common-patterns) for typical objectives. **Step 2: Identify target participants** Define participant criteria (demographics, behaviors, firmographics), sample size needed, recruitment strategy, and screening questions. For sampling strategies, see [resources/methodology.md](resources/methodology.md#participant-recruitment). **Step 3: Choose research method** Based on objective and constraints: - **For deep problem discovery (5-15 participants)** → Use [resources/template.md](resources/template.md#interview-guide-template) for in-depth interviews - **For concept testing at scale (50-200+ participants)** → Use [resources/template.md](resources/template.md#survey-template) for quantitative validation - **For JTBD research** → Use [resources/methodology.md](resources/methodology.md#jobs-to-be-done-interviews) for switch interviews - **For mixed methods** → Interviews for discovery, surveys for validation **Step 4: Design research instruments** Create interview guide or survey with bias-avoidance techniques. Use [resources/template.md](resources/template.md) for structure. Avoid leading questions, focus on past behavior, use "show me" requests. For advanced question design, see [resources/methodology.md](resources/methodology.md#question-design-principles). **Step 5: Conduct research** Execute interviews (record with permission, take notes) or distribute surveys (pilot test first). Use proper techniques (active listening, follow-up probes, silence for thinking). See [Guardrails](#guardrails) for critical requirements. **Step 6: Analyze findings** For interviews: thematic coding, affinity mapping, quote extraction. For surveys: statistical analysis, cross-tabs, open-end coding. Create insights document with evidence. Self-assess using [resources/evaluators/rubric_discovery_interviews_surveys.json](resources/evaluators/rubric_discovery_interviews_surveys.json). **Minimum standard**: Average score ≥ 3.5. ## Common Patterns **Pattern 1: Problem Discovery Interviews** - **Objective**: Understand user pain points and current workflows - **Approach**: 8-12 in-depth interviews, open-ended questions, focus on past behavior and actual solutions - **Key questions**: "Tell me about the last time...", "Walk me through...", "What have you tried?", "How's that working?" - **Output**: Problem themes, frequency estimates, current workarounds, willingness to change - **Example**: B2B SaaS discovery—interview potential customers about current tools and pain points **Pattern 2: Jobs-to-be-Done Research** - **Objective**: Identify why users "hire" products and what triggers switching - **Approach**: Switch interviews with recent adopters or switchers, focus on timeline and context - **Key questions**: "What prompted you to look?", "What alternatives did you consider?", "What almost stopped you?", "What's different now?" - **Output**: Hiring triggers, firing triggers, desired outcomes, anxieties, habits - **Example**: SaaS churn research—interview recent churners about switch to competitor **Pattern 3: Concept Testing (Qualitative)** - **Objective**: Test product concepts, positioning, or messaging before launch - **Approach**: 10-15 interviews showing concept (mockup, landing page, description), gather reactions - **Key questions**: "In your own words, what is this?", "Who is this for?", "What would you use it for?", "How much would you expect to pay?" - **Output**: Comprehension score, perceived value, target audience clarity, pricing anchors - **Example**: Pre-launch validation—test landing page messaging with target audience **Pattern 4: Survey for Quantitative Validation** - **Objective**: Validate findings from interviews at scale or prioritize features - **Approach**: 100-500 participants, mix of scaled questions (Likert, ranking) and open-ends - **Key questions**: Satisfaction scores (CSAT, NPS), feature importance/satisfaction (Kano), usage frequency, demographics - **Output**: Statistical significance, segmentation, prioritization (importance vs satisfaction matrix) - **Example**: Product roadmap prioritization—survey 500 users on feature importance **Pattern 5: Continuous Discovery** - **Objective**: Ongoing learning, not one-time project - **Approach**: Weekly customer conversations (15-30 min), rotating team members, shared notes - **Key questions**: Varies by current focus (new features, onboarding, expansion, retention) - **Output**: Continuous insight feed, early problem detection, relationship building - **Example**: Product team does 3-5 customer calls weekly, logs insights in shared doc ## Guardrails **Key requirements:** 1. **Avoid leading questions**: Phrase questions neutrally rather than telegraphing the "right" answer. Instead of: "Don't you think our UI is confusing?" use: "Walk me through using this feature. What happened?" 2. **Focus on past behavior, not hypotheticals**: What people did reveals truth; what they say they'd do is often wrong. Instead of: "Would you use this feature?" use: "Tell me about the last time you needed to do X." 3. **Use "show me" over "tell me"**: Actual behavior is more reliable than described behavior. Ask to screen-share, demonstrate current workflow, show artifacts (spreadsheets, tools). 4. **Recruit right participants**: Screen carefully. Wrong participants waste time. Define inclusion/exclusion criteria and use screening surveys. 5. **Sample size appropriate for method**: Interviews: 5-15 for themes to emerge. Surveys: 100+ for statistical significance, 30+ per segment if comparing. 6. **Seek disconfirming evidence**: Actively look for evidence against your hypothesis. If 9/10 interviews support the hypothesis, focus heavily on the 1 that does not. 7. **Record and transcribe (with permission)**: Memory is unreliable. Record interviews, transcribe for analysis. Take notes as backup. 8. **Analyze systematically**: Use thematic coding, count themes, and present contradictory evidence rather than cherry-picking supportive quotes. **Common pitfalls:** - ❌ **Asking "would you" questions**: Hypotheticals are unreliable. Focus on "have you", "tell me about when", "show me" - ❌ **Small sample statistical claims**: "80% of users want feature X" from 5 interviews is not valid. Interviews = themes, surveys = statistics - ❌ **Selection bias**: Interviewing only enthusiasts or only detractors skews results. Recruit diverse sample - ❌ **Ignoring non-verbal cues**: Hesitation, confusion, workarounds during "show me" reveal truth beyond words - ❌ **Stopping at surface answers**: First answer is often rationalization. Follow up: "Tell me more", "Why did that matter?", "What else?" ## Quick Reference **Key resources:** - **[resources/template.md](resources/template.md)**: Interview guide template, survey template, JTBD question bank, screening questions - **[resources/methodology.md](resources/methodology.md)**: Advanced techniques (JTBD switch interviews, Kano analysis, thematic coding, statistical analysis, continuous discovery) - **[resources/evaluators/rubric_discovery_interviews_surveys.json](resources/evaluators/rubric_discovery_interviews_surveys.json)**: Quality criteria for research design and execution **Typical workflow time:** - Interview guide design: 1-2 hours - Conducting 10 interviews: 10-15 hours (including scheduling) - Analysis and synthesis: 4-8 hours - Survey design: 2-4 hours - Survey distribution and collection: 1-2 weeks - Survey analysis: 2-4 hours **When to escalate:** - Large-scale quantitative studies (1000+ participants) - Statistical modeling or advanced segmentation - Longitudinal studies (tracking over time) - Ethnographic research (observing in natural setting) → Use [resources/methodology.md](resources/methodology.md) or consider specialist researcher **Inputs required:** - **Research objective**: What you're trying to learn - **Hypotheses** (optional): Specific beliefs to test - **Target persona**: Who to interview/survey - **Job-to-be-done** (optional): Specific JTBD focus **Outputs produced:** - `discovery-interviews-surveys.md`: Complete research plan with interview guide or survey, recruitment criteria, analysis plan, and insights template
More from lyndonkl/claude
- abstraction-concrete-examplesBuilds structured abstraction ladders that translate high-level principles into concrete, actionable examples across 3-5 levels. Bridges communication gaps, reveals hidden assumptions, and tests whether abstract ideas work in practice. Use when explaining concepts at different expertise levels, moving between abstract principles and concrete implementation, identifying edge cases by testing ideas against scenarios, designing layered documentation, decomposing complex problems into actionable steps, or bridging strategy-execution gaps.
- academic-letter-architectGuides the creation of evidence-based academic recommendation letters, reference letters, and award nominations that combine concrete examples, meaningful comparisons, and genuine enthusiasm. Use when writing recommendation letters for students, postdocs, or colleagues, or when user mentions recommendation letter, reference, nomination, letter of support, endorsement, or needs help with strong advocacy and comparative statements.
- adr-architectureDocuments significant architectural and technical decisions with full context, alternatives considered, trade-offs analyzed, and consequences understood. Creates a decision trail that helps teams understand why decisions were made. Use when choosing between technology options, making infrastructure decisions, establishing standards, migrating systems, or when user mentions ADR, architecture decision, technical decision record, or decision documentation.
- adverse-selection-priorProduces a Bayesian prior probability that an offered transaction is +EV for the recipient, given that the counterparty chose to propose it. Applies Akerlof market-for-lemons logic -- if they offered it, they believe it is +EV for them, so the prior that it is +EV for us is materially below 50%. Reusable across trade evaluation, waiver drops (another team dropping a player is also adverse selection), job-offer analysis, M&A, and any "someone offered me this" situation. Use when you receive an unsolicited trade/offer/proposal, analyzing incoming trade prior, evaluating why a counterparty proposed a deal, or when user mentions adverse selection, market for lemons, why did they offer this, incoming trade prior, they proposed it, Bayesian adjustment on received offer.
- alignment-values-north-starCreates actionable alignment frameworks that give teams a shared North Star (direction), values (guardrails), and decision tenets (behavioral standards). Enables autonomous decision-making while maintaining organizational coherence. Use when starting new teams, scaling organizations, defining culture, establishing product vision, resolving misalignment, creating strategic clarity, or when user mentions North Star, team values, mission, principles, guardrails, decision framework, or cultural alignment.
- analogy-weight-checkFor every analogy in a substacker draft, verifies it carries mechanical weight — the analogy does real work explaining the mechanism, not merely decorates it. Cross-references analogy-catalog.md for novelty (is this analogy reused from a prior post?) and domain fit (biology > organizational > sports preferred; physics/military disfavored). Use whenever an analogy appears in the draft. Trigger keywords: analogy weight, decorative, mechanical weight, reused analogy, catalog check, metaphor check.
- answer-uncomfortable-questionTakes one strategic question about substacker ("should we launch paid?", "is this section dead?", "are we writing for the wrong audience?") and produces the mandatory evidence + reasoning + downside triad plus a recommendation. Used 3 times per Growth Strategist review. Trigger keywords: uncomfortable question, strategic question, evidence reasoning downside, triad.
- attribute-performanceFor each substacker post that materially over- or under-performs the rolling baseline (|z| ≥ 1.0), produces a plain-English attribution paragraph with calibrated confidence (high / medium / low / unexplained). Considers subject-line effect, topic zeitgeist, external share, day-of-week, length effect, and audience-notes signals. Labels unexplained outliers explicitly rather than fabricating a story. Use after compute-baseline when outlier posts exist. Trigger keywords: attribution, why did this post work, outlier explanation, performance analysis.
- auction-first-price-shadingComputes the optimal shaded bid for a first-price sealed-bid auction given a true private value, an estimate of the number of competing bidders N, and a value-distribution assumption. Implements the `(N-1)/N` equilibrium shading rule for uniform private values, adjusts for log-normal or empirical value distributions, layers a risk-aversion adjustment, and caps output against the bidder's remaining budget. Domain-neutral auction theory reusable across fantasy sports (baseball FAAB, NBA/NHL waiver auctions), prediction-market limit sizing, sealed procurement bids, and any blind-bid context. Use when user mentions "first-price auction bid", "sealed bid shading", "(N-1)/N", "FAAB bid amount", "auction shading", "optimal bid first-price", "bid for sealed-bid", "blind bid sizing", or when downstream logic needs a principled shade factor rather than an ad-hoc heuristic.
- auction-winners-curse-haircutApplies a Bayesian haircut to a bid valuation for common-value auctions where winning is itself evidence the bidder over-estimated. Takes a raw valuation, a value-type classification (common_value / private_value / mixed), the number of informed bidders N, and a signal-dispersion estimate, and returns an adjusted valuation. Domain-neutral and reusable across fantasy FAAB, prediction markets, M&A bids, ad-auction budgets, and any generic bidding context. Use when user mentions "winner's curse", "common value auction", "valuation haircut", "adverse valuation", "Bayesian bid adjustment", or "over-paying in auction".