Experiment Sequencing: The Order Matters More Than the Method

Sequence your experiments by risk, not by convenience: test the assumption that would kill the idea if it's wrong before you test anything that only improves it, and within a risk tier, run whichever test produces the most decision-grade evidence per hour of work. Get the order wrong and you spend weeks validating a solution to a problem that doesn't exist.

Quick Answer: Rank your assumptions by how much the idea depends on them being true, not by how easy they are to test. Run the riskiest, cheapest-to-test assumption first — usually whether the problem is real and painful — before you touch pricing, design, or scale.

Prerequisites: Map Your Assumptions Before You Rank Anything

You can't sequence experiments you haven't named. Before ranking anything, write down every individual assumption the idea depends on — not the idea itself, but the specific bets buried inside it.

Most founders skip this and go straight to "what should I test first," which is backwards: without a list, "first" has no meaning, you're just picking whatever test occurred to you this morning. The Complete Guide to Startup Idea Validation walks through building that initial list end to end; this article assumes you have one and focuses on the order you work through it.

A useful way to sort the list is the four-category split David Bland and Alexander Osterwalder use in Testing Business Ideas:

• Desirability — do people actually want this, enough to change behavior for it?
• Feasibility — can you actually build and deliver it?
• Viability — will people pay enough, often enough, for it to be a business?
• Adaptability — does it survive a shifting market, competitor, or regulation?

Most early-stage ideas carry ten to twenty assumptions once written out honestly. That's fine — the next sections are about cutting that list down to an order, not testing all of them at once.

Rank Your Assumptions by Risk

Risk is two things multiplied, not added: how much the idea depends on the assumption being true, and how little evidence you currently have that it is. An assumption you're already confident about — even an important one — carries less priority than one you're genuinely unsure of, because the uncertain one is where the idea is actually exposed.

Draw a simple two-by-two: importance on one axis, evidence on the other. Assumptions in the "important, unknown" quadrant are what Testing Business Ideas calls leap-of-faith assumptions — the ones that, if wrong, don't just dent the idea, they end it. Those go first, regardless of how tedious testing them feels.

Everything else sorts around them: important-and-already-evidenced needs no re-test; unimportant-and-unknown doesn't change the decision either way; unimportant-and-already-evidenced can be skipped outright.

A common failure mode is ranking by comfort instead of risk — founders gravitate toward testing the part of the idea they're most excited about (usually the solution) rather than the part they're most exposed on (usually whether the problem is real). Risk-ranking is the corrective: it forces you to name the thing that would actually kill the idea and test that first, even when it's less fun.

Score Effort Against Evidence

Ranking by risk tells you what to test first. It doesn't tell you how — and within a risk tier, that choice matters. The lever is evidence strength per unit of effort: how much decision-grade signal a test produces relative to the time and money it costs to run.

Roughly, in order of increasing cost and increasing evidence strength:

1. Conversations — customer interviews, problem-discovery calls. Cheap and fast, weak on their own since people say things they don't do, but excellent for narrowing which assumptions are actually in play.
2. Signals of intent — landing page smoke tests, waitlist signups, click-through on a not-yet-built offer. Still cheap, and they measure behavior instead of opinion.
3. Manual delivery — concierge tests and Wizard-of-Oz experiments, where you deliver the outcome by hand behind a seemingly automated front end. More expensive in founder time, but they produce real usage data.
4. Committed money — pre-sells, letters of intent, a real price on a real checkout page. Expensive to set up properly, but nothing beats a person actually paying as evidence they'll pay.
5. Live pilots — a small paid cohort using the real product. The most expensive tier, reserved for assumptions that survived everything above it.

The mistake to avoid is jumping straight to tier 4 or 5 because it "feels more real." A pre-sell test is wasted if you haven't confirmed the problem exists — you'll build a checkout flow to learn what a thirty-minute interview would have told you for free. For guidance on where the pass/fail line actually sits, see how to set success metrics for lean experiments: sequencing tells you what to test next, but you still need a predefined bar to know whether a result counts as evidence or noise.

Map Dependencies Between Experiments

Some experiments only make sense once an earlier one has resolved. A pricing test is close to meaningless if you haven't confirmed anyone wants the thing you're pricing — you'll get a number, but not an answer you can act on. A retention experiment is premature if you haven't confirmed people will use the product even once. Dependency mapping is where you draw the arrows between assumptions so a downstream test never runs ahead of its upstream one.

The heuristic: for each assumption on your risk-ranked list, ask "does resolving this depend on already knowing the answer to something else on the list?" If yes, push it later, regardless of how it scored on risk alone. Risk tells you what matters; dependency tells you what's testable yet.

This is also where sequencing pays for itself operationally. A well-mapped chain means every experiment either kills the idea — stopping you with the least possible time and money spent — or unlocks the next one with a narrower question to test. Skip this step and you end up running technically valid experiments that don't compound: each one answers something in isolation instead of building toward a decision.

Build the Sequence

With risk, effort-to-evidence, and dependency mapped, building the actual sequence is mechanical:

1. Start with the highest-risk assumption that has no unresolved dependency. That's always test one, no exceptions.
2. Pick the cheapest test tier that can produce a real pass/fail answer. Don't reach for a pilot when an interview will do.
3. Run it, apply your predefined threshold, and make the call — proceed, pivot the assumption, or kill the idea.
4. Re-sort the remaining list. A passed test can unlock a dependency and change what's highest-risk now; a failed test can end the sequence entirely.
5. Repeat until you run out of leap-of-faith assumptions or one fails badly enough to stop.

This is the same loop the lean experiment playbook describes for designing a single test — sequencing is that loop applied across your whole assumption list. The output isn't a fixed roadmap you commit to on day one; it's a re-sortable queue, because every result changes what "next" means.

A Model Sequence: From Problem to Willingness to Pay

Most ideas, regardless of industry, converge on a similar backbone once you strip away the specifics. The table below is a generic template, not a fixed formula — skip or reorder stages that don't apply, but treat a skipped stage as a deliberate call, not an oversight.

Read this left to right, not as six mandatory boxes to tick: each stage protects you from spending stage-five or stage-six effort on an idea that would have failed at stage one. Strong existing evidence at an early stage — an established market, a competitor's public numbers, a problem you've lived personally — can justify compressing a row. What you should never do is run a stage-five test before stage one has a real answer.

Worked Example: Sequencing Six Experiments for One Idea

Take a hypothetical idea: a subscription box shipping freshly roasted, small-batch coffee beans to home baristas frustrated by stale grocery-store beans. Here's how the backbone above sequences for it.

1. Problem interviews. Fifteen conversations with people who grind their own beans, asking how they currently buy coffee and what frustrates them about it — the cheapest possible test of the riskiest assumption, that staleness is a real, felt problem and not something only the founder cares about.

2. Landing page smoke test. If interviews surface real frustration, a one-page site describing the subscription with an email-capture button, promoted to a small, targeted audience. Tests interest without roasting a single bean.

3. Concierge delivery. With signups in hand, the founder manually sources and hand-ships beans to the first ten signups for a month, doing by hand everything a platform would eventually automate — testing whether the solution itself lands before any infrastructure gets built.

4. A second-month renewal check. Of the original ten, how many want box two? Nearly free to test, since the concierge infrastructure from step three already exists.

5. A real price on a real checkout page. Only once steps one through four pass does a genuine price point get tested — not a hypothetical "would you pay $X," an actual charge. This separates "people like it" from "people will pay for it."

6. A small paid pilot with real fulfillment. With a confirmed price and confirmed renewal, the founder tests whether the economics hold once shipping, roasting cost, and churn are real numbers instead of estimates — the step that decides whether to build the business at all.

Notice what didn't happen: no packaging design, no equipment purchase, no live pricing page until the problem and the specific solution had already cleared cheaper tests. That ordering is the point — not the six specific steps, which will look different for a different idea, but the discipline of letting risk and dependency dictate what gets tested when.

The Mistake That Wrecks Sequencing: Testing Solutions Before Problems

The single most common sequencing error is building and testing a solution before confirming the problem is real. It's understandable — the solution is the part a founder has usually been thinking about for months — but it inverts the risk logic above.

The pattern: a founder sketches the UI, maybe builds a prototype, and then starts showing it around to gauge interest. Feedback is almost always positive, because people are polite and a slick demo generates enthusiasm independent of whether the underlying problem is painful enough for anyone to actually change behavior. Weeks later, real usage or real pricing reveals what interviews would have surfaced for free: nobody needed this badly enough to act.

The damage isn't just wasted build time — the sequence produced false confidence instead of no confidence. A founder who never tested the problem at least knows they don't know. One who tested the solution first and got polite enthusiasm believes they've validated something they haven't.

The fix is the risk-ranking step from earlier, applied honestly: before writing a line of code or a design brief, ask "if this problem turns out not to be real, does anything downstream survive?" If not, that's your leap-of-faith assumption, and it goes first — even when the solution is what you're itching to build.

Key Takeaways

• Rank by risk, not by ease. The assumption that would kill the idea if wrong goes first, regardless of how unglamorous testing it feels.
• Match test cost to what you already know. Cheap tests burn down early uncertainty; expensive tests are reserved for assumptions that already survived a cheaper filter.
• Map dependencies before scheduling. An experiment that depends on an unresolved upstream assumption produces a number, not an answer.
• The sequence is a re-sortable queue, not a fixed roadmap. Every result changes what "highest risk, untested" means for the next round.
• Problem before solution, every time. Testing a solution before confirming the problem is real produces false confidence, which is more expensive to unwind than no confidence at all.
• A predefined pass/fail threshold matters as much as the order. Sequencing tells you what to test next; a metric tells you whether the result counts as a pass.

Frequently Asked Questions

How many experiments should I run before deciding whether to build?

There's no fixed number — it depends on how many leap-of-faith assumptions your idea carries and how quickly each clears. Stop when every important assumption has cleared its threshold, or one has failed badly enough to end the idea in its current form.

What if two assumptions seem equally risky?

Break the tie with cost: run whichever is cheaper to test first. You lose nothing by testing the cheap one first, even if it turns out to matter slightly less — you've bought the same information for less time and money either way.

Can I test several assumptions in parallel instead of one at a time?

Only if they're genuinely independent — meaning neither result changes how you'd design the other test. If one depends on another, running them in parallel just means finishing both without knowing whether the dependent one was worth running. When in doubt, treat it as sequential.