conducting-user-interviews
Help users run better customer and user interviews. Use when someone is preparing for user research, planning discovery interviews, writing interview questions, analyzing interview findings, or trying to understand customer needs.
What this skill does
# Conducting User Interviews Help the user run better discovery conversations and extract real insights using techniques from 43 product leaders. ## How to Help When the user asks for help with user interviews: 1. **Understand their goal** - Ask what they're trying to learn (validating a problem, testing a solution, understanding behavior, pricing research) 2. **Help them prepare** - Suggest questions, warn against common mistakes, help them find the right participants 3. **Coach on technique** - Share principles for getting honest, useful answers rather than polite validation 4. **Help analyze findings** - Assist in synthesizing what they learned into actionable insights ## Core Principles ### Collect stories, not opinions Teresa Torres: "Interviewing is a grossly underestimated skill. If you're not collecting rich stories, you won't identify opportunities." Don't ask "What do you like?" Ask "Tell me about the last time you..." ### Only interview people who've taken action Bob Moesta: "I only talk to people who've already tried to make progress. What made them try? Ignore 'bitching' (complaining)—look for 'switching' (actual behavior change)." ### Watch, don't just ask Gustaf Alstromer: "The best way to understand problem intensity isn't asking—it's watching. Have them screen share and walk through their daily workflow. Look for pain they've normalized." ### Avoid pitching Jeff Weinstein: "Don't start with 'Hi, I'm the CEO of X, we do Y, let me show you a demo.' What a wasted opportunity. Listen first. Use silence to let them open up." ### Falsify, don't validate Judd Antin: "We don't validate, we falsify. We look to be wrong. Many PMs want to be right—they do user-centered performance, not real research." ### Never ask what they want built Judd Antin: "A researcher who asks customers what they want is a bad researcher. Focus on understanding behaviors and problems—not having users design your solution." ### Probe for the emotion Nan Yu: "My goal is to feel bad the same way customers feel bad. Dig past the feature request to find the underlying negative emotion motivating it." ### Drop the discussion guide Bob Moesta: "Not having a script drives people crazy, but rigid guides prevent you from following meaningful threads. Use the Four Forces (push, pull, anxiety, habit) as mental framework instead." ### Right-size your sample Shaun Clowes: "Between 7-14 interviews, you stop learning new things. Less than 7, not enough data. More than 14, diminishing returns." ### Expect 90% rejection Gustaf Alstromer: "90% of people aren't early adopters. You need to reach 10 to find 1. Rejection isn't failure—it's filtering for the right users." ### Get direct exposure Marty Cagan: "I wasn't allowed to make product decisions until I'd visited 30 customers. Those visits changed my life—I thought I knew our customers and I really didn't." ### Respond with extreme speed Jeff Weinstein: "When a customer goes out of their way to share a problem, that's a gift. I'll leave a meeting to reply. Be 'text message friendly' with 5-10 power users." ### Interview the non-users Mihika Kapoor: "The most insightful conversations are with non-users. Ask why they're not using your product—you'll find perception gaps users can't see." ### Test willingness to pay Jeff Weinstein: "Have them send you a $1 invoice right now. The gap between 'willingness to pay' and actually paying is massive. This tests real commitment." ### Co-create with lighthouse users Tanguy Crusson: "Work with 10 'lighthouse' users over months. Put them in Slack with your team. Involve engineers directly so they build empathy." ## Questions to Help Users - "What are you trying to learn from these interviews?" - "Are you interviewing people who've already tried to solve this problem?" - "How are you recruiting participants?" - "What's your opening question? (Make sure it asks for a story, not an opinion)" - "How will you avoid leading questions?" - "What will you do with the findings?" ## Common Mistakes to Flag - **Leading questions** - "Don't you think X would be better?" just gets agreement - **Asking about hypotheticals** - "Would you use this?" is meaningless; behavior matters - **Pitching during research** - You're there to learn, not sell - **Too few interviews** - 2 isn't enough; aim for 7-14 - **Delegating observation** - PMs and designers must be in the room, not reading reports ## Deep Dive For all 64 insights from 43 guests, see `references/guest-insights.md` ## Related Skills - Analyzing User Feedback - Defining Product Vision - Measuring Product-Market Fit - Designing Surveys
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.