The Validation Stack: How All These Frameworks Fit Together

The validation stack is the order these frameworks actually work in: discover whether the problem is real, research who has it, check who else is already solving it, score which assumption to test first, then run an experiment that produces real evidence. Five layers, run in sequence — not five competing methodologies to pick between.

Quick Answer: Layer your validation work in five steps — problem discovery, customer research, competitive analysis, scoring, and experiments — using each layer's output as the next layer's input. Most framework confusion disappears once you see them as stages in one pipeline instead of a pile of unrelated templates.

Why founders drown in frameworks — the missing connective map

Founders drown in frameworks because every guide teaches one framework in isolation, so you end up learning ten separate tools and no map of how they connect. The missing piece isn't a better framework. It's the sequence.

Picture the shelf of guides it would take to learn every framework by name: one on the Mom Test, one on Jobs-to-be-Done, one on the Lean Canvas, one on RICE scoring, one on smoke tests. Each is complete and useful on its own terms. None of them tells you what happens right before it or right after it — so you're left holding ten hammers with no sense of which wall you're supposed to be building.

That gap produces two familiar failure modes. The first is filling in every framework you can find without ever testing anything against a real customer — a pattern already covered in The Startup Validation Toolkit. The second is getting stuck perfecting a single layer, usually research, because nothing told you when it's finished and safe to leave. The fix for both is the same: know which layer you're in, and know what evidence lets you leave it.

This guide is that connective map. It doesn't re-teach each framework from scratch — the dedicated guides already do that — it shows where each one sits in the pipeline, what question it's responsible for answering, and what it hands off to the next layer.

The validation stack, layer by layer

Here is the entire stack in one table: five layers, the frameworks most founders reach for in each, and the single question each layer has to answer before you're allowed to move on.

Read the table top to bottom for a brand-new idea. Read it as a diagnostic once you're stuck: whichever layer you keep circling back to, unresolved, is the one still holding an unanswered question. You rarely need more than one or two frameworks per layer — the table lists common options, not a checklist you're required to complete in full.

Layer 1: Problem discovery — is this pain real?

Problem discovery answers one question: does this problem already exist in someone's life, unprompted, badly enough that they've tried to solve it themselves? If you can't find people already limping around it with a spreadsheet, a manual workaround, or a competitor's half-solution, you don't have a validated problem yet — you have a hunch with good production values.

Three frameworks do this work. Mom Test–style interviews ask about a person's past behavior instead of their opinion of your idea, so you can't accidentally coach a polite yes out of them. Jobs-to-be-Done reframes the problem as the progress someone is trying to make — Clayton Christensen's example of someone "hiring" a milkshake to make a boring commute more bearable is the canonical illustration of the lens. Customer Development, Steve Blank's framework, compresses to one instruction: leave the building and talk to real people before writing a line of code.

You know you're done with this layer when you can describe the problem in the customer's own words, backed by a handful of independent conversations that landed on the same complaint without you suggesting it. If every interview describes a different problem, the problem isn't defined yet — go back to interviews, not to a canvas.

Layer 2: Customer research — who has it, and how many?

Customer research answers a narrower question than discovery: not whether the problem is real, but who specifically has it, how many of them exist, and whether they can pay for a fix. Discovery establishes that the pain is genuine; research establishes whether there's a market attached to it.

This layer draws on the interviews from discovery but widens the lens considerably:

• Persona mapping turns a handful of interview transcripts into a composite profile — role, context, current workaround, and who actually controls the budget.
• Rough market sizing (a top-down TAM/SAM/SOM pass, or simply "how many people or companies look like this") tells you whether the addressable group is a market or a handful of people you happen to know personally.
• Demand-signal research — search volume for the underlying problem, activity in relevant forums or communities, money already being spent on a workaround — corroborates the interviews with evidence you didn't have to ask anyone for.

Skip this layer and you risk a specific trap: confirming the problem is real for the five people you interviewed, then discovering there are only five people quite like them. Research is what turns "someone has this problem" into "enough people have this problem to build a business on."

Layer 3: Competitive analysis — who else is already solving it?

Competitive analysis answers whether anyone is already solving this problem well enough that customers have stopped looking — and if so, exactly where that solution still falls short. No competition at all is rarely good news. It usually means the market is smaller than it looks, or willingness to pay hasn't been proven yet.

Three things earn their place here. A feature-gap audit of the two or three closest existing options — direct competitors and adjacent substitutes — mapped against what your interviews said people actually need, not everything a competitor's marketing site claims. A positioning check, plotting yourself against competitors on the one or two dimensions your customers said matter most, not the dimensions that flatter your idea. And a substitute inventory: spreadsheets, a manual process, a competitor's product used off-label, or simply doing without — all of it counts as competition, because it's what you have to be meaningfully better than to earn a switch.

Treat an empty competitive landscape as a flag to investigate, not a green light to build. Genuinely uncontested, well-sized markets are rare. More often it means demand hasn't been proven yet, or earlier entrants tried and quietly failed for a reason worth understanding before you repeat it.

Layer 4: Scoring — which assumption do you test first?

Scoring answers a sequencing question, not a validation question: of everything you still don't know, what should you test first? By this layer you typically have more open assumptions than time to test them, and a scorer turns a pile of guesses into a defensible order.

A Lean Canvas is the fastest way to get every assumption — problem, solution, channels, revenue, unfair advantage — onto one page where you can circle the single box that would kill the idea if you're wrong about it. Once you're choosing among several ideas or features rather than one glaring risk, RICE (Reach × Impact × Confidence ÷ Effort) or its faster cousin ICE gives you a repeatable order instead of whichever option feels loudest that week. Full walkthroughs of both frameworks, including how to score each input, live in The Startup Validation Toolkit.

The score itself is disposable. A two-decimal RICE result isn't a fact — it's your judgment made explicit. Its real value is forcing you to write down a Confidence estimate; when that number comes out low, you've just found what to research or test next, before you've spent a day building on top of it.

Layer 5: Experiments — proving it with behavior, not opinion

Experiments answer the question none of the previous four layers can: does this actually work, measured by what people do rather than what they say? Everything upstream — discovery, research, competitive analysis, scoring — is preparation for designing one falsifiable test with a pass/fail line set in advance.

Eric Ries's The Lean Startup names the loop this layer runs on: build the smallest thing that produces a signal, measure real behavior against a threshold you set beforehand, and learn whether to persevere or pivot. The loop, not any single experiment, is the reusable part.

Which specific experiment you build depends on what you're testing. A landing page or smoke test checks whether people will act on a claim before the product exists. A concierge MVP has you personally deliver the service by hand, so you learn what actually needs automating later. A Wizard of Oz test lets the product look automated while a human quietly does the work behind the scenes. David J. Bland and Alexander Osterwalder's Testing Business Ideas catalogs many more, organized by the kind of assumption — desirability, feasibility, or viability — each one is built to test. For a full breakdown of when to reach for which experiment, see The Lean Experiment Playbook.

This is also the layer where "I validated my idea" stops being a feeling and starts being a specific number you set a threshold for before you looked at the result.

The full journey — a worked path from raw idea to PMF evidence

Here's what the five layers look like end to end, walked through with one raw idea as a running example — not because your idea will look like this one, but because the sequence matters more than the specifics.

Say your idea is a scheduling tool built specifically for freelance music teachers, who currently juggle lessons across text messages, a paper calendar, and a payments app that doesn't talk to either.

1. Discovery. Ten conversations with freelance teachers turn up the same complaint unprompted: reschedules get lost in text threads and someone doesn't show up. That's a discovery result — the problem is real and specific, not a hypothesis anymore.
2. Research. You size the group — freelance instrumental teachers in your target region — and check search and community activity for the underlying pain, not for your product name. Teacher forums full of the same complaint, attached to a large enough group, confirm what discovery found.
3. Competitive analysis. You map the two general-purpose scheduling tools teachers currently misuse, plus the manual workaround — text plus paper — they've settled for instead. The gap: nothing handles the specific back-and-forth of a last-minute lesson swap; the general tools only handle a clean, static slot.
4. Scoring. A Lean Canvas surfaces the riskiest assumption, and it isn't whether teachers want this — it's whether they'll actually change payment habits, since money is the messiest part of the current workaround. That becomes the assumption tested first, ahead of anything about the calendar interface.
5. Experiments. You run a concierge version — manually coordinating reschedules and payments for a dozen teachers over a month, using ordinary tools behind the scenes — with a pass/fail line set beforehand: at least eight of twelve still using it, unprompted, by week four. The result is your evidence, not your enthusiasm.

Stack enough passed experiments like that one and you eventually cross into product-market fit — the point where demand starts outpacing what you can deliver and retention holds without you chasing it. Anything short of that is still layer five, not the finish line.

Common mistakes: tool hopping and stage skipping

The two most common ways to misuse this stack are tool hopping — swapping frameworks within a layer instead of finishing it — and stage skipping — jumping straight to scoring or experiments before discovery and research have actually happened.

Watch for these specifically:

• Tool hopping. Trying Jobs-to-be-Done, then the Mom Test, then a survey, all for the same discovery question, because none of them delivered a comfortable answer. Switching methods rarely fixes an uncomfortable result; talking to more people with the same method usually does.
• Skipping straight to experiments. Building an MVP before running discovery interviews, so the "experiment" tests a solution to a problem nobody has described in their own words yet. The build-measure-learn loop only teaches you something if what you're measuring was worth building in the first place.
• Skipping competitive analysis because "there's no competition." Almost always means a substitute wasn't recognized as competition — the spreadsheet, the manual process, the doing-without.
• Treating a scoring number as a verdict. A RICE score is a discipline for making judgment explicit, not a fact independent of the guesses that fed it.
• Staying in discovery forever. The opposite failure — never leaving layer one because no interview feels conclusive enough, when the real blocker is reluctance to face what the next layer's evidence might say.

None of these are framework problems. They're sequencing problems, and the fix in every case is the same: name which layer you're actually in, finish its one question, and move to the next.

Key Takeaways

• The validation stack has five layers, not five competing choices. Problem discovery, customer research, competitive analysis, scoring, and experiments run in sequence, each layer's output feeding the next.
• Discovery only counts once you have unprompted, independent evidence. A handful of interviews converging on the same complaint, without you suggesting it, is what makes a problem real rather than assumed.
• Research turns "someone has this problem" into "enough people have it." Persona mapping, rough market sizing, and demand signals confirm the problem discovery surfaced actually has a market attached to it.
• An empty competitive landscape is a flag, not a green light. It usually means demand isn't proven yet, or a substitute — a spreadsheet, a workaround — is already absorbing the pain.
• A scoring number is your judgment made explicit, not an independent fact. Its value is surfacing low-confidence assumptions worth testing before you build on top of them.
• Every experiment needs a pass/fail line set before you look at the result. That's what separates evidence from a comforting story told about behavior after the fact.
• Tool hopping and stage skipping are the same mistake pointed in different directions. Both avoid finishing the layer you're actually stuck in — know which one that is before reaching for a new framework.

Frequently Asked Questions

What order should I use these startup validation frameworks in?

Run them in the five-layer order this guide maps: problem discovery first, then customer research, competitive analysis, scoring, and experiments last. Each layer needs the one before it genuinely finished — scoring an idea before discovery just ranks guesses, not evidence.

Do I need to complete every layer for every idea?

Not with equal depth. A well-understood market might need only a light competitive-analysis pass, and an idea you've already partly tested might move straight to scoring. But skipping a layer entirely — especially problem discovery — is the most common cause of building something nobody independently confirmed they needed.

How is scoring different from just going with my gut?

Scoring frameworks like RICE and ICE force you to write down separate estimates for reach, impact, confidence, and effort instead of one blended feeling, which makes weak assumptions visible instead of hidden inside a single gut call. The number itself isn't more objective than your gut — the discipline of breaking it apart is what actually helps.

How do I know when I've reached product-market fit instead of just early interest?

Early interest is people saying they like the idea; product-market fit is retention holding without you chasing it, plus demand starting to outpace what you can currently deliver. The worked journey above walks through what that evidence looks like in practice — treat anything short of it as still layer five, not the finish line.

How long does going through the whole validation stack take?

There's no fixed timeline — it depends on how quickly you can get real conversations and a running experiment, not on how fast you fill in templates. As a rough rule of thumb rather than a benchmark, discovery through scoring is usually days to a couple of weeks of calendar time, and each experiment then needs its own window — often two to six weeks — to produce a behavioral signal you can actually trust.