Validating a SaaS idea means proving, with evidence rather than opinion, that a specific group of people has a problem painful enough to pay for a solution — before you build one. The ten steps below are the checklist I run with founders before any build work starts, and the single most common reason it gets skipped is that founders find building more fun than validating.
1. Write the one-sentence problem statement
Before any interviews, write who has the problem, what they do today instead of a solution, and why that current approach is painful enough to change. If you can't write this in one sentence without hedging, you don't have a validated problem yet — you have a hunch.
2. Run 10-15 problem interviews
Talk to real prospective users about what they do today, not whether they'd use your idea. Ask about the last time they hit the problem, what it cost them, and what they tried. Hypothetical answers ('I'd definitely use that') are the least reliable signal in the whole process — behaviour beats opinion every time.
3. Look for a specific, repeated workaround
Real problems have real workarounds: a spreadsheet, a manual process, a competitor's product used badly for this purpose. If nobody has built or bought anything to solve this, that's not necessarily disqualifying, but it raises the bar of proof you need before building.
4. Size the market honestly
Not a top-down TAM slide — a bottom-up count of how many people or companies plausibly have this problem in a form you could reach in twelve months. A painful problem with three hundred addressable customers might still be a great lifestyle business; it's a different conversation for a venture-scale pitch.
5. Test willingness to pay before building
Ask directly what they currently spend solving this problem, and float a rough price for your solution. If people flinch at any price, or say they'd need budget approval from three people, that's information worth having now rather than after a six-week build.
6. Try to pre-sell it
A verbal or written commitment to buy — a deposit, a signed letter of intent, a waitlist with a real email captured after seeing a concrete mockup — is worth more than any survey. If nobody will commit to anything before it exists, the demand may be politeness rather than intent.
7. Check the competitive and substitute landscape
Search for existing solutions, including adjacent ones people might already be misusing to solve this problem. A crowded space isn't automatically disqualifying — it often confirms the problem is real — but you need a specific, defensible reason customers would switch to you.
8. Define the one metric that proves the wedge
Decide, before building anything, what number would tell you the MVP worked: a completed booking, a returned user in week two, a converted trial. This becomes your eval criterion and stops the post-launch conversation from drifting into vanity metrics like signups or page views.
9. Build the smallest possible test
A working prototype, a concierge version done manually, or even a well-designed landing page with a real payment link — whatever gets you the fastest, cheapest signal on real behaviour. Resist the urge to build the full product before you've tested the wedge; that's how six-week MVPs become six-month ones.
10. Set a kill criterion in advance
Decide upfront what result means you stop or pivot — for example, fewer than three pre-sales from twenty qualified conversations. Deciding this before you have a result protects you from rationalising a disappointing outcome once you're emotionally invested in the idea.
This ten-step checklist is essentially the Discover and Validate stages of the Crossley Method laid out in detail — the same two stages that precede Prototype and Build MVP in the full seven-stage framework (Discover, Validate, Prototype, Build MVP, Launch, First Revenue, Scale). Skipping straight to building without working through these steps is the single biggest predictor of a wasted MVP budget I see in fractional CPO work.
Frequently asked questions
- How long should SaaS idea validation take?
- For most SaaS ideas, one to two weeks of focused interviews, pre-selling and lightweight testing is enough to make a build/no-build decision, provided the ten steps are run with discipline rather than dragged out indefinitely.
- What's the biggest mistake founders make when validating a SaaS idea?
- Asking hypothetical questions ('would you use this?') instead of looking at real past behaviour and asking for a real commitment now, such as a pre-sale or a deposit. Opinions about the future are the least reliable form of validation.
- Do you need a prototype to validate a SaaS idea?
- Not always — interviews, pre-selling and market sizing can validate a lot before any building happens. A working prototype or concierge test becomes valuable once you need to test actual behaviour with the real product, not just intent.
- How many customer interviews are enough to validate an idea?
- Ten to fifteen focused problem interviews is usually enough to spot a clear pattern, provided the questions focus on past behaviour and specific workarounds rather than hypothetical future use.