Continuous Discovery
Run a weekly customer-discovery cadence with opportunity trees, assumption tests, and interview snapshots so shipping stays tied to outcomes.
Overview
continuous-discovery is an agent skill most often used in Validate (also Idea research, Build pm) that builds weekly customer touchpoints with Opportunity Solution Trees and assumption testing before you commit delivery
Install
npx skills add https://github.com/wondelai/skills --skill continuous-discoveryWhat is this skill?
- Embeds discovery as a weekly rhythm—not a pre-build phase gate
- Covers Opportunity Solution Trees, assumption mapping, and interview snapshots
- Targets at least one customer touchpoint per week for product trios
- Connects experience mapping, co-creation, and outcome-based roadmaps to delivery
- Explicit handoffs: use mom-test for interviews and inspired-product for team structure
- At least one customer touchpoint per week target stated in framework core principle
Adoption & trust: 2k installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You ship features from stakeholder opinions or stale research because customer discovery is a one-time phase instead of a weekly habit.
Who is it for?
Solo founders and tiny product trios running SaaS or agent-backed products who need structure for ongoing interviews and outcome-based roadmaps.
Skip if: Builders who only need a single usability test script or pure engineering task lists with no customer learning component.
When should I use this skill?
User mentions continuous discovery, opportunity solution tree, weekly interviews, assumption testing, discovery habits, product trio, or outcome-based roadmap; or when setting regular feedback loops and prioritizing expe
What do I get? / Deliverables
You get a repeatable weekly discovery loop—trees, assumptions, and snapshots—that prioritizes experiments and links evidence to what you build next.
- Opportunity Solution Tree artifacts
- Assumption map and prioritized experiments
- Interview snapshots linked to delivery
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate is the canonical shelf because the framework centers on proving which opportunities and assumptions deserve build investment before delivery expands. Scope fits prioritizing experiments, mapping opportunities, and narrowing what to test—not one-off landing hacks or pure competitor desk research.
Where it fits
Schedule weekly mom-test-style interviews and capture snapshots before you narrow which problem space to validate.
Map opportunities on a tree and rank assumption tests so you do not over-build the wrong MVP.
Co-create solutions with recent interview evidence before committing to a prototype scope.
Feed discovery snapshots into sprint priorities so delivery tracks outcome metrics, not vanity features.
Keep weekly touchpoints after launch to discover retention and expansion opportunities from real usage.
How it compares
Use as a discovery operating system instead of ad-hoc chat advice about talking to users once before launch.
Common Questions / FAQ
Who is continuous-discovery for?
Indie builders and product trios who own roadmap and validation and want Teresa Torres–style habits encoded for their coding agent.
When should I use continuous-discovery?
In Validate when scoping experiments and assumptions; in Idea research when setting weekly interview cadence; in Build pm when connecting discovery insights to delivery and backlog priorities.
Is continuous-discovery safe to install?
It is procedural guidance with no bundled binaries; review the Security Audits panel on this page and treat customer data from interviews according to your own privacy practices.
SKILL.md
READMESKILL.md - Continuous Discovery
# Continuous Discovery Habits Framework Framework for building a sustainable, weekly practice of customer discovery that keeps product teams making progress toward desired outcomes. Rather than treating discovery as a phase that happens before development, this framework embeds customer learning into the ongoing rhythm of product work so that every decision is informed by fresh evidence. ## Core Principle **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 goal is at least one customer touchpoint per week, every week, by the product trio (product manager, designer, engineer). ## Scoring **Goal: 10/10.** When reviewing or creating a product discovery practice, rate it 0-10 based on adherence to the principles below. A 10/10 means the team has a weekly interview cadence, maintains a living Opportunity Solution Tree, systematically tests assumptions, and uses evidence to decide what to build. Lower scores indicate gaps in cadence, structure, or rigor. Always provide the current score and specific improvements needed to reach 10/10. ## Framework ### 1. Opportunity Solution Trees **Core concept:** An Opportunity Solution Tree (OST) is a visual map that connects a desired outcome at the top to customer opportunities in the middle and potential solutions at the bottom. It makes implicit product thinking explicit and shared. **Why it works:** Most teams jump from a business outcome straight to solutions, skipping the customer need entirely. The OST forces teams to first understand the opportunity space -- the unmet needs, pain points, and desires customers have -- before generating solutions. This prevents building features nobody wants. **Key insights:** - The tree has four layers: Outcome > Opportunities > Solutions > Experiments - Opportunities are customer needs, pain points, or desires -- framed from the customer's perspective - A single outcome typically has many opportunities; a single opportunity can have many solutions - The tree is a living artifact -- updated weekly as the team learns - Breaking large opportunities into smaller sub-opportunities makes them actionable - Teams should pursue multiple opportunities simultaneously, not bet everything on one **Product applications:** | Context | Application | Example | |---------|-------------|---------| | Quarterly planning | Define the outcome, then map the opportunity space before committing to features | "Increase trial-to-paid conversion" as outcome, then discover why users don't convert | | Feature prioritization | Compare solutions across different opportunities to find highest-leverage bets | Three solutions for "users can't find relevant content" vs. two for "onboarding is confusing" | | Stakeholder alignment | Use the tree as a shared visual to align on strategy and tradeoffs | Walk leadership through the tree to show why you chose opportunity X over Y | **Ethical boundary:** Never cherry-pick opportunities to justify a predetermined solution. The tree must reflect genuine customer needs discovered thr