Lean Startup Hypothesis Template: Testable Hypotheses

Use a lean startup hypothesis template to turn vague business assumptions into falsifiable statements with a metric and pass mark set before testing.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A testable hypothesis is an assumption rewritten so that evidence can prove it wrong. A lean startup hypothesis template gives the rewrite a fixed shape: who, what they will do, how you will measure it and what result counts as right. This skill covers how to find the assumptions worth writing up, how to phrase each one so an experiment can settle it, and how to set the pass mark before the test.

Hypotheses are the starting point of the whole method. Eisenmann, Ries and Dillard describe lean startups as firms that convert their vision into testable business model hypotheses and validate them with minimum viable products (HBS note, Hypothesis-Driven Entrepreneurship). The Lean Startup method calls the riskiest of these the leap-of-faith assumptions. If the hypothesis is vague, every later step inherits the vagueness: the MVP has no clear target, the metric is chosen after the fact and the result can be read either way.

Ries distinguishes two hypotheses for a new product. An article on the Lean Startup Co. site summarizes them this way: the value hypothesis "tests whether your new product or service will create value for the customer," and the growth hypothesis "tests how new customers will adopt the product" (Lean Startup Co.). Most useful hypotheses are pieces of one or the other. Sorting your assumptions under these two headings is a quick way to see which ones the business depends on.

The test of a good hypothesis is whether the team can say, before the experiment, which result would count as a failure. "Customers want a simpler invoicing tool" cannot fail. "Freelancers who send invoices monthly will create and send one invoice through our tool within a week of signing up, and at least half of sign-ups will do so" can. The second version names a customer, an action, a timeframe and a threshold.

The output of the skill is a short list of hypotheses, ranked by risk, each in the same format. That list feeds experiment design and becomes the record against which results are judged.

How It Works

Two templates are widely used. Strategyzer's Test Card has four lines: "We believe that" for the hypothesis, "To verify that, we will" for the test, "And measure" for the metric, and "We are right if" for the criteria (Strategyzer Test Card). Jeff Gothelf's Lean UX format reads: "We believe [this statement is true]. We will know we're [right/wrong] when we see the following feedback from the market," followed by qualitative feedback, quantitative feedback or a change in a key performance indicator (Gothelf, Lean UX). Both force the same discipline: a belief paired with the evidence that would confirm or refute it.

A falsifiable hypothesis has four parts. The subject is a specific customer segment, described by situation and behavior. The action is something observable that customers will do, such as sign up, pay, return or refer. The measure is how you will count that action. The threshold is the result that separates right from wrong, set before the test. Missing any part makes the hypothesis hard to test. A missing subject lets any audience count. A missing threshold lets any result count.

Behavior beats opinion. A hypothesis that customers will "like" or "be interested in" something has no observable action. Rewrite it around what they will do and what it costs them. Payment, time and reputation are strong signals. Clicks are weaker. Survey answers about future plans are weakest.

Thresholds come from the business model. Ask what result would make the business work if it held at scale, and what result would make it clearly unworkable. The pass mark sits near the first, and a fail mark near the second. Writing both, as Tristan Kromer recommends for innovation accounting criteria (Kromer), leaves room for an honest in-between result.

Ranking completes the work. Each hypothesis gets two ratings: how bad it would be if it were wrong and how much evidence you already have. The one with the highest impact and the least evidence is tested first. The Test Card's "critical" field captures the first rating directly.

Step-by-Step Guide

Step 1: List everything that must be true

Write down every assumption behind the plan: who the customer is, what problem they have, how they solve it today, why they would switch, what they would pay, how they would find you and what it costs to serve them. Write fast and include assumptions that feel obvious. Obvious assumptions are often the ones nobody has checked.

Step 2: Sort into value and growth

Put each assumption under the value hypothesis or the growth hypothesis, using the Lean Startup Co. definitions. Value assumptions are about whether customers get enough from the product to use and pay for it. Growth assumptions are about how new customers will find and adopt it. Anything that fits neither may not matter yet.

Step 3: Rank by impact and evidence

Rate each assumption on how damaging it would be if wrong and how much evidence supports it. Pick the few with high impact and little evidence. Those are the leap-of-faith assumptions to write up first. Leave the rest on the list for later rounds.

Step 4: Rewrite each one with the template

For each chosen assumption, fill in the template: "We believe that [specific customers] will [observable action] [in this setting]." Replace any opinion word with an action. Replace any broad group with a segment you could recruit. Read it aloud and ask whether a stranger could tell from it who to test and what to watch.

Step 5: Add the measure and the thresholds

Name the metric that counts the action and how it will be recorded. Set a pass mark and a fail mark, each with a timeframe, based on what the business model needs. Write what you will do in each case. If the team cannot agree on a fail mark, the hypothesis is not yet testable.

Step 6: Check for falsifiability and scope

Review each hypothesis against a short checklist: one assumption per statement, a named segment, an observable action, a metric, a threshold and a timeframe. Split compound statements joined by "and". Remove hedges such as "might" or "some". Then pass the hypotheses to experiment design in rank order.

Best Practices

• Write the fail mark as carefully as the pass mark. A hypothesis that cannot fail cannot teach you anything.
• Use the customer's own words for the problem. Language from customer discovery interviews keeps the hypothesis grounded in what people actually said.
• Keep one assumption per hypothesis. Compound statements produce results you cannot attribute.
• Tie thresholds to the business model. A pass mark picked because it sounds reasonable tells you little about whether the business works.
• Keep a single, versioned list. When a hypothesis is revised after a test, record the old version and the reason for the change.
• Revisit the ranking after each result. A passed hypothesis often changes which assumption is now the riskiest.

Common Mistakes

• Writing opinions instead of behavior: "Users will love the dashboard" has no observable action. Rewrite it as something users will do, such as return to the dashboard weekly.
• Leaving out the threshold: Without a pass mark, any result looks encouraging. Set it before the test and share it.
• Testing the solution before the problem: A hypothesis about a feature assumes the underlying problem is real. Test the problem hypothesis first, often through interviews.
• Hypothesizing about everyone: "Small businesses" is too broad to recruit or measure. Name a segment by situation and recent behavior.
• Changing the hypothesis after the result: Rewriting the statement to fit the data destroys the learning. Record the result against the original and write a new hypothesis for the next test.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Lean Startup

Related Skills

• Designing Validated Learning Experiments
• Customer Discovery Interview Questions and Technique
• How to Build a Minimum Viable Product (MVP)
• Types of MVP: How to Choose the Right Format
• Running the Build-Measure-Learn Loop
• Innovation Accounting Metrics: Tracking Real Progress
• Pivot or Persevere: When to Pivot a Startup

Sources

• Eisenmann, Ries and Dillard: Hypothesis-Driven Entrepreneurship
• Lean Startup Co.: Avoiding 4 misapplications of The Lean Startup
• Strategyzer: The Test Card
• Jeff Gothelf, Lean UX: hypothesis statement format
• Tristan Kromer: Pivot or persevere decision

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.