How to validate a startup idea before you build anything.

This guide covers how to validate a startup idea the way founders actually need it: with the framework, the common mistakes, and the evidence to back the work.

Most founders validate in the wrong direction. They build something, then look for evidence it was a good idea. The research confirms what the conviction already decided. The result is a product nobody needed, built by someone who interviewed ten enthusiastic people and called that market research.

Proper validation runs the process in reverse. You start with the conditions that would make the idea fail, then test whether those conditions are true. If none of them are true, you have something worth building. If any of them are true, you have learned something valuable before spending a year of your life on it.

The core problem with how founders typically validate is that they ask forward-leaning questions. Would you use this? Would you pay for this? Do you have this problem? People answer yes to all three for products they would never actually buy, because yes is easier than no, and because the future tense lets them opt into a hypothetical without commitment.

According to CB Insights' 2023 analysis of 300 post-mortem startup reports, 42 percent of failures cited the absence of genuine market need as the primary cause. That number has been consistent across CB Insights' surveys since 2019. It is not a new problem. Founders have always known validation matters. The issue is that the most common validation methods produce confirming evidence rather than disconfirming evidence.

A landing page that collects email addresses is not validation. It is a signal that your copywriting was interesting enough to get an email address from someone who was curious. A survey with 200 respondents who said they would pay between $20 and $50 per month is not validation. It is a signal that 200 people were willing to spend 3 minutes answering questions. Neither tells you whether a specific human being, with a specific budget, in a specific procurement context, will actually pay you money.

A kill criterion is a specific, testable condition that, if true, means the business cannot work as described. It is not a risk. It is a binary condition. Before you run a single customer interview, write down three conditions that would cause you to not build the idea.

For a B2B SaaS product targeting compliance teams at mid-market companies, the kill criteria might look like this. First: no compliance officer at a company with 50 to 500 employees controls a discretionary software budget above $10,000 per year. If true, the unit economics of the business break because the buyer does not control enough budget to make a direct sale viable. Second: the incumbent vendor (likely a spreadsheet plus a consultant) has a switching cost above $50,000 due to integration debt. If true, the cost of switching is higher than three years of your annual contract value, which means rational buyers will not switch. Third: the regulatory requirement this product addresses is jurisdiction-specific, and the total US addressable market is fewer than 15,000 companies. If true, the market is not large enough to support a venture-backed company.

These are not pessimistic. They are testable. You can find out whether each one is true through desk research, industry filings, and five targeted conversations. The purpose of naming kill criteria first is to focus your validation on the highest-risk assumptions rather than the assumptions you feel comfortable about.

Before you run customer interviews, build a bottoms-up market size estimate. Not a Gartner headline. A model that starts with a specific buyer, counts how many of them exist, estimates the price they will pay, and multiplies.

For the compliance SaaS example: there are approximately 127,000 companies in the United States with between 50 and 500 employees that operate in financial services, healthcare, or technology sectors with active compliance obligations, according to the 2022 Census Bureau Statistics of US Businesses. Of those, roughly 40 percent have at least one dedicated compliance function, not just a part-time responsibility assigned to legal. That produces a serviceable addressable market of approximately 50,800 companies. At $8,400 annual contract value (a $700 per month price point), the SAM is approximately $427 million. A 3 percent market penetration over five years is $12.8 million ARR, which is achievable with a direct sales motion.

That model is falsifiable. Every number can be checked, updated, or corrected. If the Census Bureau count is wrong, you update it. If the price point is wrong, you update it. The act of building the model forces you to make your assumptions explicit and testable.

Before you talk to customers, understand what they are doing now. The question is not whether your solution is better. The question is whether the current solution is good enough to create rational inertia against switching.

Current solutions exist on a spectrum. At one end are dedicated software products from established vendors. At the other end are spreadsheets, manual processes, and consultants. The position of your target buyer on that spectrum determines the switching cost they face and the argument you need to make to displace the current solution.

If your target buyers are using spreadsheets, the switching cost is low but the trigger for switching is also low. They are not in enough pain to have bought a solution yet, which means your first job is to articulate a problem they do not currently frame as a problem. If your target buyers are using an incumbent product, the switching cost is high but the pain is real and named. Your job is to make the case that the switching cost is worth bearing.

Map the landscape by reading job postings (they tell you what tools companies currently use), product review sites (they tell you what users complain about), and LinkedIn (it tells you who holds the role you are targeting and what their career history looks like). Spend four hours on this before you book a single customer interview.

Five conversations is not a statistically significant sample. It is enough to test whether the problem you have described exists in the specific, named form you believe it does. If the problem does not appear in five targeted conversations with the right type of buyer, you either have the wrong buyer profile or the wrong problem description.

Each conversation should follow a consistent structure. Start with the current state: what does this person's process look like today for the thing your product would replace? Do not mention your product yet. Let them describe the current state in their own language. Then move to consequences: what happens when this process breaks down, and how often does that happen? Then move to economics: how much time does this process take, and who is involved? Do not ask what they would pay for a solution. Ask what it would be worth to eliminate the problem they just described.

The economics question is the most important and the most skipped. Founders typically end the interview at the consequence stage, having confirmed that the problem exists and that the person is frustrated by it. But frustration is not a purchase decision. You need to understand whether the economic case for buying your product is sound for this specific buyer, with their specific budget, in their specific procurement context.

According to research published in the Harvard Business Review in 2021 covering 1,100 B2B purchase decisions, 75 percent of the time the economic case for a purchase was made or broken in informal conversations with peers before any formal vendor evaluation began. That means your buyer has probably already decided the economic case before they talk to you. Your job in the interview is to surface what that case looks like, not to construct it.

Most founders test price too late. They build the product, set a price based on competitive analysis, and then discover in sales conversations that the price is either too high for the buyer's budget or too low to signal the value the product delivers. Both are recoverable, but recovering from them after you have built the product is far more expensive than testing before.

Price testing before building does not require a product. It requires a precise description of outcomes. Tell the buyer what the product will do in specific, outcome-oriented terms. Not "it automates your compliance reporting." Say "it reduces the time your team spends compiling evidence for SOC 2 audits from an average of 14 days per audit to under 4 days, and it produces an audit-ready report in the format your external auditor requires." Then ask: what budget would you allocate to a tool that delivered that outcome reliably?

The answers you get will be imprecise and optimistic, because buyers underestimate what they will actually spend. But they will tell you whether you are in the right order of magnitude. If five buyers independently say something between $3,000 and $8,000 annually, you have a signal that a $6,000 annual contract is in range. If three of them say "we would not pay anything for that, we use our consultant for $2,000 a year and it is good enough," you have learned something critical before writing a line of code.

Return to the three kill criteria you wrote in step one. For each one, what did the research tell you? If the first kill criterion was "no compliance officer controls a budget above $10,000," what did your five interviews suggest? Did buyers reference software budgets in that range, higher, or lower? What did job postings for the role suggest about budget authority?

You are not trying to prove the kill criteria are false. You are trying to find the best available evidence on each one. If the evidence is mixed, that is useful information. If the evidence strongly suggests a kill criterion is true, that does not mean you abandon the idea. It means you need to redesign the model to work under that constraint, or accept that the constraint makes the model unworkable.

The output of this step is not a score or a pass/fail grade. It is a clear articulation of which assumptions are validated, which are not, and what additional evidence would change your assessment. That is the document you should be able to show an investor before you raise, and show yourself before you quit your job.

Good validation produces a specific answer to this question: under what conditions does this business work, and do those conditions currently exist? The answer should name the buyer, the price, the switching cost, the market size, and the two or three conditions most likely to undermine the model if they turn out to be false.

It does not produce a deck slide that says the market is $4.7 billion. It does not produce a testimonial from an enthusiastic potential user. It produces a structured set of tested assumptions and a clear map of the residual risks, ranked by their likelihood of being true and their impact on the model if they are.

The hardest part of validation is conducting it as a genuine inquiry rather than as a process of confirmation. Founders who believe in their idea tend to select the customers most likely to validate it, ask questions most likely to generate positive responses, and discount the negative signals they receive as outliers or misunderstandings.

The fix is to treat disconfirming evidence as more valuable than confirming evidence. If a customer tells you the problem does not exist, or that the current solution is adequate, or that the price you need to charge is above their budget, that is a more useful data point than ten enthusiastic yeses. The yeses tell you the idea is interesting. The nos tell you whether the idea is viable.

Verdikt's research process is built around this principle. Every report we produce names the kill criteria explicitly, cites the evidence for and against each one, and delivers a verdict that is defensible precisely because it does not start from conviction. The goal is not to confirm your idea. The goal is to test it against reality before reality tests it for you, at a far higher cost.