{"id":"continuous-discovery","name":"continuous-discovery","summary":"機会ソリューションツリー、仮定マッピング、インタビュースナップショットを用いて、毎週の顧客接点のリズムを作りましょう。","body":"# Continuous Discovery Habits Framework\n\nFramework for building a sustainable weekly practice of customer discovery that keeps product teams progressing toward desired outcomes. Discovery is not a phase before development — it is embedded in the ongoing rhythm of product work so every decision is informed by fresh evidence.\n\n## Core Principle\n\n**Good product discovery requires a continuous cadence, not a one-time event.** Teams that talk to customers every week, map opportunities visually, and test assumptions before building consistently outperform teams that rely on intuition, stakeholder opinions, or quarterly research cycles. The benchmark: at least one customer touchpoint per week, every week, by the product trio (product manager, designer, engineer).\n\n## Scoring\n\n**Goal: 10/10.** Score a discovery practice by the seven Quick Diagnostic rows below — start at 3, add 1 point per row answered \"yes\" (max 10). Bands: **9-10** = weekly cadence, a living Opportunity Solution Tree, systematic assumption testing, and every shipped feature traceable to a customer opportunity; **5-6** = some discovery happening but ad hoc, PM-only, or disconnected from delivery; **≤3** = intuition- and stakeholder-driven with no regular customer contact. Report the current score, the failing rows, and the specific fix for each.\n\n## Framework\n\n### 1. Opportunity Solution Trees\n\n**Core concept:** An Opportunity Solution Tree (OST) visually connects a desired outcome (top) to customer opportunities (middle) to potential solutions and experiments (bottom), making implicit product thinking explicit and shared.\n\n**Why it works:** Most teams jump from business outcome straight to solutions, skipping the customer need entirely; the OST forces understanding of the opportunity space first, preventing features nobody wants.\n\n**Key insights:**\n- Four layers: Outcome > Opportunities > Solutions > Experiments\n- Opportunities are customer needs, pain points, and desires — framed from the customer's perspective\n- The tree is a living artifact, updated weekly as the team learns\n- Break large opportunities into smaller sub-opportunities to make them actionable\n- Pursue multiple opportunities simultaneously — don't bet everything on one\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| Quarterly planning | Map the opportunity space before committing to features | \"Increase trial-to-paid conversion\" → discover why users don't convert |\n| Feature prioritization | Compare solutions across opportunities for the highest-leverage bet | Three solutions for \"can't find content\" vs. two for \"confusing onboarding\" |\n| Stakeholder alignment | Use the tree as the shared strategy visual | Walk leadership through why you chose opportunity X over Y |\n\n**Ethical boundary:** Never cherry-pick opportunities to justify a predetermined solution — the tree must reflect needs discovered through research.\n\nSee [references/opportunity-trees.md](references/opportunity-trees.md) when building or auditing a tree — adds the 4-layer diagram, good-vs-poor outcome tables, solution-generation techniques, a weekly update rhythm, healthy/dying-tree signals, two worked examples, and four anti-patterns.\n\n### 2. Experience Mapping\n\n**Core concept:** Current-state experience maps capture how customers accomplish a goal today, step by step, revealing pain points that become opportunities on the tree.\n\n**Why it works:** Teams assume they understand the customer's current experience; mapping it from interview data exposes gaps, workarounds, and emotions invisible from inside the building.\n\n**Key insights:**\n- Map the current state, not a future ideal — understand reality first\n- Include actions, thoughts, and feelings at each step\n- Build collaboratively with the full trio, sourced from interview data, not assumptions\n- Experience maps cover the customer's full experience; journey maps cover only your product's touchpoints\n- Pain points and high-emotion moments become OST opportunities\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| New problem space | Map end-to-end before designing | How a small business owner handles invoicing, from creation to chasing payment |\n| Churn analysis | Map churned users' experience to find failure points | Users abandon onboarding at step 4 — they lack data they need on hand |\n| Cross-functional alignment | Build the map together | A three-hour collaborative session produces one shared reference artifact |\n\nSee [references/experience-mapping.md](references/experience-mapping.md) when mapping a new problem space or churn flow — adds the current-state map template, the experience-vs-journey-map distinction, and the collaborative mapping exercise.\n\n### 3. Interview Snapshots\n\n**Core concept:** Story-based interviews capture specific past experiences (not opinions or predictions), and each interview is synthesized into a one-page snapshot the whole team can absorb and reference.\n\n**Why it works:** Customers are poor predictors of their own future behavior; grounding insights in real past events reveals what they actually did and felt, and snapshots turn each interview into a growing library of evidence.\n\n**Key insights:**\n- Ask about specific past behavior: \"Tell me about the last time you...\" not \"Would you use...?\"\n- Each snapshot captures the story, key quotes, opportunities identified, and an identifier\n- The trio interviews together so insights aren't lost in translation\n- Automate recruitment so interviews happen weekly without heroic effort\n- Patterns across snapshots reveal opportunities; single interviews only reveal stories\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| Weekly cadence | Standing 30-minute interview slots | Recruit via in-app prompt; rotate who leads |\n| Opportunity discovery | Extract needs from stories onto the OST | A data-export workaround becomes an opportunity node |\n| Team alignment | Share snapshots visibly | A board where snapshots accumulate and patterns emerge |\n\n**Ethical boundary:** Never lead participants toward conclusions — ask open-ended questions about past behavior and let the story reveal what matters.\n\nSee [references/interview-snapshots.md](references/interview-snapshots.md) when running interviews or setting up recruitment — adds story-based interview structure, the one-page snapshot format, synthesis across snapshots, and how to automate weekly recruitment.\n\n### 4. Assumption Testing\n\n**Core concept:** Before building, identify the assumptions a solution depends on, map them by importance and evidence, then run small fast tests on the riskiest ones first.\n\n**Why it works:** Every solution sits on a stack of desirability, viability, feasibility, and usability assumptions; most teams test none — or only the easy ones — and invest months in solutions built on false premises.\n\n**Key insights:**\n- Four assumption types: desirability (do they want it?), viability (can we sustain it?), feasibility (can we build it?), usability (can they use it?)\n- Map on a 2x2: importance vs. evidence; high-importance, low-evidence = leap-of-faith assumptions to test first\n- Design the smallest test that generates evidence: one-question surveys, painted-door tests, prototypes, data mining\n- Set success criteria before running the test: \"validated if...\"\n- One assumption test should take days, not weeks\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| Before building | Test the riskiest assumption of the top candidates | \"Users will share reports with their manager\" → painted-door button before building sharing |\n| Comparing solutions | Test each candidate's riskiest assumption to eliminate weak options fast | A's riskiest assumption fails, B's passes → pursue B |\n| De-risking a roadmap | Find untested assumptions hiding in committed features | Q3 feature assumes users want real-time notifications — no evidence yet |\n\n**Ethical boundary:** Never deceive participants — painted-door tests should say the feature is coming soon, not fake functionality without disclosure.\n\nSee [references/assumption-mapping.md](references/assumption-mapping.md) when designing a test for a risky assumption — adds the four assumption types in depth, the importance-vs-evidence 2x2, the test-design menu, and how to set success criteria for leap-of-faith assumptions.\n\n### 5. Prioritizing Opportunities\n\n**Core concept:** Compare opportunities against each other — not in isolation — using opportunity size, market, company, and customer factors to find the highest-leverage bets.\n\n**Why it works:** Teams default to the loudest stakeholder, recency bias, or gut feel; structured head-to-head comparison forces explicit tradeoff discussions and surfaces disagreements before implementation.\n\n**Key insights:**\n- Relative comparison beats independent scoring\n- Size opportunities by how many customers are affected, how often, how severely\n- Weigh strategy alignment, team capability, and existing evidence\n- Make a good-enough decision quickly, then learn fast — avoid analysis paralysis\n- Revisit the ranking as new evidence arrives\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| Quarterly planning | Rank the top 5-7 OST opportunities | \"Can't find content\" vs. \"no real-time collaboration\" via structured criteria |\n| Sprint planning | Pick the opportunity with the strongest current evidence | Choose where you have the most interview data and a testable solution |\n| Portfolio decisions | Spread effort by risk and impact | 60% high-confidence, 30% medium, 10% exploratory |\n\nSee [references/prioritization-methods.md](references/prioritization-methods.md) when ranking your top opportunities — adds the opportunity-sizing method, the compare-and-contrast technique, how to weigh data, and how to avoid analysis paralysis.\n\n### 6. Building the Habit\n\n**Core concept:** Continuous discovery only works as a sustainable weekly habit for the trio — automate recruitment, create lightweight rituals, and embed discovery into the existing workflow rather than treating it as extra work.\n\n**Why it works:** Discovery that depends on \"finding time\" loses to delivery pressure every week; structural support (automated recruitment, standing slots, shared artifacts) removes the per-week decision so the habit survives and compounds.\n\n**Key insights:**\n- The whole trio participates — not just the PM\n- Automate recruitment: in-app intercepts, advisory panels, scheduling tools that fill slots\n- Block recurring calendar time — discovery that depends on \"finding time\" never happens\n- Fill in the snapshot immediately after the interview, not days later\n- Start with one interview per week; connect insights to the OST and from there into sprint planning\n\n**Product applications:**\n\n| Context | Application | Example |\n|---------|-------------|---------|\n| Team kickoff | Establish cadence in week one | Automated recruitment, blocked Thursday slot, snapshot template |\n| Scaling discovery | Grow from one to three interviews weekly | Add a churned-user slot and a prospect slot |\n| Manager support | Leaders protect time and ask for evidence | \"What did you learn from interviews this week?\" in every 1:1 |\n\n**Ethical boundary:** Respect participant time — keep interviews to 30 minutes, compensate fairly, and never disguise a sales pitch as discovery.\n\nSee [references/case-studies.md](references/case-studies.md) when adapting the habit to your context — worked walkthroughs of continuous discovery in B2B SaaS, consumer mobile, platform, and growth teams.\n\n## Common Mistakes\n\n| Mistake | Why It Fails | Fix |\n|---------|-------------|-----|\n| Discovery as a phase before development | Insights go stale; team builds on old assumptions | Embed discovery into every week alongside delivery |\n| Only the PM talks to customers | Designer and engineer lose context in translation | The full trio interviews together |\n| Jumping from outcome to solutions | Skips the opportunity space | Build an OST to make it explicit |\n| Asking customers what they want | You get feature requests, not needs | Story-based interviewing: \"Tell me about the last time...\" |\n| Testing easy assumptions, not risky ones | False confidence; the fatal assumption goes untested | Map by importance and evidence; test high-risk first |\n| Scoring opportunities in isolation | Everything looks important | Compare head-to-head with structured criteria |\n| Interview burst, then stopping | No compounding learning | Automate recruitment; block recurring time |\n\n## Quick Diagnostic\n\n| Question | If No | Action |\n|----------|-------|--------|\n| One customer conversation per week minimum? | Decisions lack fresh evidence | Automate recruitment; block a weekly slot |\n| A living Opportunity Solution Tree? | Strategy is implicit and unshared | Build an OST from your outcome and interview data |\n| Full trio in interviews? | Insights filtered through one person | Invite the designer and engineer to the next one |\n| Testing assumptions before building? | Betting on untested premises | Map your next feature's assumptions; test the riskiest |\n| Can you trace a shipped feature to a customer opportunity? | Delivery disconnected from discovery | Link backlog items to OST opportunities |\n| Interview snapshots visible to the whole team? | Knowledge trapped in one head | Shared snapshot board, filled after each interview |\n| Comparing opportunities, not just listing them? | Prioritization by opinion | Run a structured comparison on your top 5 |\n\n## Further Reading\n\nBased on the continuous discovery framework developed by Teresa Torres:\n\n- [*\"Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value\"*](https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?tag=wondelai00-20) by Teresa Torres\n\n## About the Author\n\n**Teresa Torres** is an author, speaker, and coach who has helped hundreds of product teams — from startups to Capital One and Calendly — adopt continuous discovery. She created the Opportunity Solution Tree, writes the widely read Product Talk blog, and distilled her coaching practice into *Continuous Discovery Habits*.","author":"@wondelai","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/wondelai/skills/tree/main/continuous-discovery","license":"MIT","category":"document","lang":"en","tokens":2818,"stars":0,"calls30d":1,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/assumption-mapping.md","size":14288,"sha256":"d7af13b9c027d96a716562a92c4f4d5272d2a77a465a0f0abaa8cde253ff9340"},{"path":"references/case-studies.md","size":18814,"sha256":"fe16d19696145d00a7df863a2d52264da7286083de1b1a4db59e5267dad082e6"},{"path":"references/experience-mapping.md","size":15306,"sha256":"3e9ae975233adc7f8478b199518aa81c620c129872a95de543c3871314f6e597"},{"path":"references/interview-snapshots.md","size":15185,"sha256":"3806b3cb32cab0b2d47254f19d67f8cde9371569d883e0161eed09089260848d"},{"path":"references/opportunity-trees.md","size":10725,"sha256":"ee7f3e4b5c15689e0a6389a6585a7878e1ed45252fc1132a62005091d03c1c5d"},{"path":"references/prioritization-methods.md","size":14741,"sha256":"71b7322f7899e1b63b860843c7da9661fdab5aec3f4f8c19aff9bb53a034e156"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":["www.amazon.com"]}}