Validating a SaaS Idea

Idea validation is the process of gathering evidence that a problem is real, painful, frequent, and worth paying to solve before committing months of engineering to a full product. The goal is not to prove the idea is good. The goal is to learn quickly whether it is worth pursuing, and to design experiments that can disprove it cheaply.

A SaaS idea has three separable bets: that the problem matters, that the solution works, and that the business can reach customers profitably. Most failed products were technically fine but solved a problem nobody urgently had, or could not be sold for more than it cost to acquire a customer. Validation tests the riskiest assumptions first, in the order that would kill the idea fastest.

What validation is not

It is not asking friends whether they like the idea. They will be polite.
It is not building a polished MVP and waiting for users. That is a bet, not a test.
It is not a survey asking “would you use this?” Hypothetical interest does not predict behavior.
It is not a single yes/no event. It is a sequence of small experiments that lower risk over time.

The riskiest-assumption mindset

Before running experiments, write down the assumptions the idea depends on, then rank them by risk (how likely they are to be false) and impact (how badly a false answer hurts). Test the highest-risk, highest-impact assumption first.

Typical assumptions for a SaaS idea:

A specific group of people has this problem often enough to care.
The problem is painful enough that they already spend time or money on it.
They can find and adopt a software solution (budget, authority, technical fit).
You can reach them through a repeatable, affordable channel.
They will pay a price that exceeds your cost to acquire and serve them.

Each experiment should target one assumption and have a clear pass/fail threshold set in advance. Deciding what counts as success after seeing the data is how teams talk themselves into bad ideas.

Strategies

These are the broad approaches. Pick based on how much you already know and how risky the core assumption is.

Problem-first validation, confirm the problem exists and hurts before describing any solution. Best when entering an unfamiliar market.
Demand testing, measure whether people act on an offer (sign up, pay, book a call). Best when the problem is known and the question is whether your solution sells.
Concierge and Wizard of Oz, deliver the outcome manually behind a simple interface so you learn what the product must do before building automation.
Pre-selling, take money or a signed commitment before the product exists. The strongest signal available short of a live product.
Competitor and workaround analysis, study what people already pay for or cobble together. Existing spend is proof of willingness to pay.

Tactics

Problem interviews

Talk to people in your target segment about how they handle the problem today. The aim is to extract facts about past behavior, not opinions about your idea.

Actionable steps:

Recruit 10 to 20 people who plausibly have the problem. Use your network, communities, LinkedIn, and cold outreach.
Ask about the last time the problem occurred: what happened, what they did, what it cost in time or money.
Ask what tools or workarounds they use now, and what they dislike about them.
Listen for emotion and specifics. Vague answers mean low pain.
Do not pitch. The moment you describe your solution, people switch from reporting reality to being polite.

Good questions: “Walk me through the last time this happened.” “What did you do about it?” “How much time or money did that cost?” “What have you tried to fix it?” “What happens if you do nothing?”

Avoid: “Would you use a tool that does X?” “Do you think this is a good idea?” “How much would you pay?” These invite speculation, not evidence.

Landing page demand test

Publish a focused page that describes a specific outcome and asks for one clear action. Drive a small amount of targeted traffic and measure conversion.

Actionable steps:

Write a headline naming the audience and the outcome, not the technology.
Add a single call to action: join the waitlist, request access, or book a call.
Send traffic from one or two channels (a relevant community, a small ad budget, a content post, or direct outreach).
Track visits to signups so you can compute conversion rate.
Follow up with everyone who signs up. Their replies are richer signal than the raw number.

Concierge MVP

Manually deliver the result your software would eventually produce, for a handful of real users, in exchange for their honest engagement or payment. You learn the true workflow before automating it.

Wizard of Oz

Show users what looks like a working product while a human performs the work behind the scenes. Useful when the interface needs to feel real but the automation is expensive to build.

Pre-sales and letters of intent

Ask for money, a deposit, or a signed letter of intent before building. A credit card or a contract beats encouragement by a wide margin. For B2B, a letter of intent from someone with budget authority is a strong proxy.

Fake door and smoke tests

Add a button or pricing option for a capability that does not exist yet, then measure how many people click or attempt to buy. Always disclose honestly once they engage, and capture their interest.

Signals to trust, and signals to discount

Trust:

People already paying for an inferior workaround or a generic tool.
Repeated, unsolicited complaints about the same workflow.
Users who give you their time, their data, or their money without being chased.
A waitlist that converts to calls, and calls that convert to commitments.

Discount:

“That’s a great idea.” Praise costs nothing.
“I would definitely use that.” Future-tense intent rarely becomes behavior.
High survey interest with zero follow-through when asked to act.
Enthusiasm from people who are not in your target segment or cannot buy.

The reliable pattern: weight what people do (sign up, pay, switch) far above what people say they would do.

Choosing metrics and thresholds

Define the number that would make you continue, pivot, or stop before you run the test.

Interview pain score, what fraction described a costly, recent, recurring problem in concrete terms.
Landing page conversion, signup rate from targeted traffic. Treat it as relative signal across variants, not an absolute benchmark.
Pre-sale conversion, fraction of interested prospects who commit money or a signed intent.
Activation in a concierge test, did users actually adopt the manual workflow and come back.
Channel cost, rough cost to reach one interested prospect, an early read on whether acquisition can be affordable.

A practical sequence

Frame the bet, write the target segment, the problem, and the riskiest assumption.
Run problem interviews, 10 to 20 conversations to confirm the problem is real and painful.
Test demand, a landing page or direct offer to see if people act.
Deliver manually, a concierge or Wizard of Oz run with a few committed users.
Pre-sell, ask for money or a signed commitment before building.
Decide, continue to an MVP, pivot the assumption, or stop and recycle the energy into the next idea.

Move to the next step only when the current one clears its threshold. Each step costs more, so cheap tests should come first.

Common pitfalls

Testing the solution before confirming the problem exists.
Pitching during interviews and collecting politeness instead of facts.
Setting success criteria after seeing the results.
Talking only to people who are easy to reach rather than people who can buy.
Treating a survey of stated intent as evidence of demand.
Building a full product just to “see if anyone wants it”, which is the cost validation is meant to avoid.
Ignoring the buyer in B2B: the user who feels the pain may not control the budget.
Falling in love with the idea and unconsciously designing experiments that cannot fail.

When to stop or pivot

Kill or change the idea quickly when interest is consistently flat, when no one will commit time or money, or when the only enthusiasm comes from outside your target segment. Stopping is not failure; it is the return on cheap experiments. The strongest founders treat a disproven hypothesis as saved months and move the energy to the next one.

What comes after validation

Validation reduces risk; it does not remove it. Once the problem, demand, and willingness to pay look credible, the next questions are scoping a minimum viable product, choosing a model and price point (see Pricing your first product), and finding a repeatable acquisition channel. Validation continues after launch as you measure retention and move toward product-market fit.