Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Discovery hypothesis builder

Converts raw user insights, interview notes, and data signals into a ranked set of testable product hypotheses, each framed with an explicit assumption, evidence base, riskiest unknown, and a designed validation…

download .md

Purpose

Turn messy discovery inputs — interview quotes, support tickets, usage data, survey responses — into a ranked set of testable hypotheses, each tied to its evidence, its riskiest assumption, and a concrete experiment to validate it. Solves the gap between "we heard something interesting" and "here's exactly what we're going to test and how we'll know we're right."

When to Use

Invoke this skill when the user asks to:

  • Synthesize user interviews or research notes into product hypotheses
  • Turn a data signal or usage anomaly into something testable
  • Decide what to test next in a continuous discovery cycle
  • Reframe a feature request or stakeholder opinion as a falsifiable assumption
  • Map out validation experiments before committing engineering effort
  • Build a hypothesis backlog or opportunity-solution tracking artifact

Inputs Required

Before starting, collect:

  • Raw insights: Interview quotes, support themes, survey verbatims, or observed behaviors (paste them raw — synthesis is the job)
  • Data signals (if any): Metrics, drop-off points, funnel anomalies, or usage patterns
  • Product area: The feature, flow, or surface these insights touch
  • Target user / segment: Who these insights came from and who the bets serve
  • Desired outcome: The business or user outcome the team is trying to move (e.g., activation rate, retention, time-to-value)
  • Constraints: Time to validate, access to users, instrumentation available, or team capacity

If the desired outcome is missing, infer it from the insights and state the assumption explicitly. If no data signals are provided, build hypotheses from qualitative inputs alone and flag where quantitative validation is needed.

Instructions

Step 1: Cluster the Raw Insights

Group the inputs into 3–6 distinct insight themes. For each cluster:

  • Theme name: A short, human label (e.g., "Users don't trust the auto-import")
  • Supporting evidence: The specific quotes, tickets, or data points that belong to it (cite them — don't paraphrase away the signal)
  • Evidence strength: Strong (multiple independent sources / data + qual) / Moderate (repeated qual, no data) / Weak (single source or anecdote)
  • Interpretation gap: What's an observation vs. what's already an assumption sneaking in

Do not skip weak-evidence themes — flag them, because they often become the riskiest hypotheses.

Step 2: Convert Each Theme into a Structured Hypothesis

For every theme worth pursuing, write a hypothesis in this format:

We believe [target user] experiences [problem/need] because [observed reason]. If we [proposed change/intervention], we expect [measurable outcome], because [underlying causal assumption].

Each hypothesis must be:

  • Falsifiable: There must be a result that would prove it wrong
  • Outcome-linked: Tied to the desired outcome, not just an output ("ship the feature")
  • Single-variable: One core bet — split compound hypotheses into separate entries

Step 3: Surface the Riskiest Assumption

For each hypothesis, name the leap of faith — the single assumption that, if false, collapses the whole bet. Categorize it:

  • Desirability: Do users actually want this?
  • Viability: Does it serve the business outcome?
  • Feasibility: Can we build it?
  • Usability: Can users actually use it?

The riskiest assumption — not the most comfortable one — drives what gets tested first.

Step 4: Design a Validation Experiment per Hypothesis

For each hypothesis, specify:

  • Method: Interview / prototype test / fake-door / A/B test / instrumentation analysis / concierge / survey
  • Test setup: What you'll show or measure, with how many users or what sample
  • Signal of success: The specific, pre-committed threshold that confirms the hypothesis (e.g., "≥6 of 8 users complete the flow unprompted")
  • Signal of failure: What result kills or pivots the hypothesis
  • Effort to validate: Hours/days, Low / Medium / High

Match the lightest method that can credibly de-risk the assumption — don't propose an A/B test when 5 interviews would answer it.

Step 5: Rank the Hypotheses

Score each on two axes:

  • Risk: How much is unknown / how damaging if the assumption is wrong (High = test sooner)
  • Value: How much it moves the desired outcome if true

Rank so the high-risk, high-value hypotheses surface first. Present as: Test Now (high risk + high value), Test Soon (high value, lower risk), Park (low value or already well-evidenced).

Step 6: Recommend the Next Test

Name the single hypothesis to test next, the experiment to run, and the decision it unlocks. Be specific about what the team learns and what they do with each outcome. Be opinionated.

Output Format

  • Structure: Insight clusters → numbered hypothesis entries (each with structured statement, riskiest assumption, experiment) → ranked Test Now / Test Soon / Park table → next-test recommendation
  • Length: 900–1,400 words
  • Format: Structured document — clustered prose for synthesis, consistent labeled blocks per hypothesis, a ranking table
  • Sections: Insight Clusters → Hypotheses (structured) → Hypothesis Ranking (table) → Recommended Next Test
  • Tone: Discovery coach — rigorous, falsification-minded, allergic to untested certainty; speaks like someone who's been burned by shipping on assumptions

Quality Checklist

Before delivering output, verify:

  • [ ] Every hypothesis uses the full "We believe… If we… we expect… because…" structure
  • [ ] Each hypothesis is falsifiable — there is a stated result that disproves it
  • [ ] Every hypothesis names exactly one riskiest assumption, categorized by D/V/F/U
  • [ ] Each experiment has a pre-committed success threshold and a failure signal — not "see if it works"
  • [ ] The ranking puts high-risk, high-value hypotheses in Test Now — not the easiest ones
  • [ ] Evidence is cited from the raw inputs, not paraphrased into generic claims

Notes

  • The most common failure is hypotheses that can't be wrong ("Users want a better experience") — force a falsifiable, measurable form every time
  • Test the riskiest assumption first, not the most fun one to build; comfort-zone testing wastes discovery cycles
  • In a continuous discovery cadence, treat this as a recurring synthesis ritual — rerun it weekly against fresh interview notes and let the Park list decay or resurface
  • A hypothesis with Strong evidence may not need a test at all — note when the next step is to build, not validate

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills