Written by Simon, founder who shipped 4 products nobody wanted.
Startup Idea Validation: The Decision Stack Framework
Most founders validate backwards. They spend weeks building a landing page, run a few ads, get 200 email signups and decide the idea is proven. Then they spend six months building, launch to those 200 people, and discover that exactly four of them actually wanted to pay for it. The rest just liked the concept. This happens not because founders are careless, but because they validate the wrong things in the wrong order. The Decision Stack Framework exists to fix that.
Startup idea validation is not a single experiment. It's a sequenced system where each phase only begins after the previous one passes a clear threshold. The order matters more than the specific methods you use. Get the sequence wrong and you're burning time testing feasibility on a product nobody wants, or pricing a solution for a market too small to sustain a business. Validate your idea before you write a line of code or hire anyone, and you'll save yourself months of misdirected effort.
Why Sequential Validation Beats Parallel Testing
The instinct to test everything at once feels efficient. Run the landing page, do the interviews, sketch the architecture, model the unit economics, all in week one. In practice, parallel testing creates noise. You can't act on what you learn from feasibility if you haven't confirmed desirability yet. Validating whether you can build something before confirming anyone wants it is like optimizing the engine on a car you haven't decided to buy.
Sequential validation works because each layer of assumption has a different cost to test and a different consequence if wrong. The cheapest test is always the one you run first. If nobody wants the thing, feasibility is irrelevant. If it's technically impossible, pricing experiments are a waste. The Decision Stack locks in this order: desirability first, feasibility second, viability third.
The Three Layers of Assumption Hierarchy
Desirability is the foundation. Does the problem you're solving actually hurt people enough that they'd pay to fix it? This is the layer most founders think they've already validated because they personally experience the problem. That's not validation. That's anecdote. You need fifteen to twenty conversations with people who are not your friends, not people who owe you honesty because they like you. You're listening for problem frequency, current workarounds and emotional intensity. A good signal is when someone describes the problem unprompted and tells you how they currently cope.
Feasibility comes second. Can you actually build a solution that addresses the job-to-be-done? This isn't just a technical question. It includes whether the regulatory environment allows it, whether key integrations exist, whether your team has the capability or can acquire it in a reasonable timeframe. The Wizard-of-Oz MVP is your best tool here: simulate the product manually, deliver the outcome by hand, and see whether the delivery mechanism even matters to the user or whether they just want the result.
Viability is the layer founders rush to because it involves spreadsheets and feels like real business. But viability analysis on a desirability or feasibility failure is vanity. Once the first two layers are confirmed, you need to know whether the market is large enough, whether people will pay your target price and whether the unit economics can sustain the business at scale. Pre-payment experiments (not surveys, actual money changing hands) are the only honest viability signal.
The 30-90 Day Sequential Validation Roadmap
Weeks one and two are documentation. This sounds boring. Do it anyway. Write down every assumption baked into your idea, and rank them by the risk they carry if proven wrong. According to HBS Online's market validation guide, writing down goals and hypotheses before testing is step one for a reason: it prevents you from unconsciously adjusting your beliefs to fit the results you wanted. Before you test anything, define what success looks like. Not