How to Validate SaaS Ideas in 7 Steps (2026 Checklist)

You validate SaaS ideas by collecting evidence — before you build — that a specific group of people has a painful, recurring problem, that they already spend time or money coping with it, and that at least a few of them will commit to paying for a better solution. That is how to validate SaaS ideas in practice: interviews about past behaviour, a check of existing demand, a landing page smoke test, and a real commitment such as a deposit or a signed pilot.

Compliments, likes and “great idea” replies are not validation. This guide walks through the seven steps in the order that gives you the cheapest evidence first, with a pass/fail signal at the end of each step and a scored checklist at the end so you can make a clear decision: build, pivot, or park the idea.

If you are still at the shortlist stage, work through a list of profitable SaaS ideas worth testing first and pick one candidate. Validation works on one idea at a time — trying to validate three ideas at once usually means none of them gets enough evidence to judge.

What SaaS idea validation is — and what it is not

Validation is the process of testing the riskiest assumptions behind an idea with the smallest possible effort, before the expensive part (building the product) begins. Your idea rests on assumptions: that the problem is real, that it happens often, that a reachable group of people has it, that current solutions leave them frustrated, and that they will pay to fix it. Each step in this guide tests one or two of those assumptions with real behaviour, not opinions.

Validation is:

• Evidence from behaviour — what people have done, tried and paid for in the past
• A sequence of increasingly costly tests, so you can stop as soon as the answer is “no”
• A decision tool: its output is a written verdict, not a feeling
• Something you do before an MVP, to decide what the MVP should even contain

Validation is not:

• Asking friends, family or followers whether they like your idea
• A landing page with no traffic, or a waitlist counted as proof of demand on its own
• A survey asking people to predict their own future behaviour (“Would you pay $20 a month for this?”)
• A guarantee. Validation reduces the biggest, cheapest-to-test risks. It cannot prove a product will succeed, and anyone who promises otherwise is selling something

One distinction matters throughout: interest is not intent. Interest is free to give — a click, a like, a polite “sounds useful”. Intent costs the person something: their time in an interview, their email for a specific offer, a reply to a follow-up, a deposit, a signed letter of intent. Weight every signal in this guide by what it cost the person giving it.

The 7 steps at a glance

1. Turn the idea into a testable problem statement
2. Define one specific first customer
3. Interview customers about past behaviour
4. Check existing demand and alternatives
5. Run a landing page smoke test
6. Ask for a real commitment
7. Score the evidence and decide: build, pivot or park

You do not need any code for steps 1–6, and most founders can work through them in two to four weeks alongside a day job, provided they can actually reach the customers they want to interview. Slow access to customers — not the tests themselves — is what usually stretches the timeline.

Step 1: Turn the idea into a testable problem statement

Most ideas arrive as solutions: “an app that automates X”, “a dashboard for Y”, “an AI tool that does Z”. Solutions cannot be validated, because there is nothing to test except taste. Problems can. Your first job is to restate the idea as a problem, in one sentence, without naming your product:

[Specific customer] loses [time / money / opportunities] because [job or process] currently involves [painful workaround], and this happens [how often].

How to do it:

1. Write your idea at the top of a page, then list every assumption hidden inside it: who has the problem, how often it happens, what it costs them, what they do about it today, and what they would switch for.
2. Rewrite the idea using the sentence format above. If a bracket stays empty, that is not a writing problem — it is an assumption you have not checked yet. Mark it as unknown rather than filling it with a guess.
3. Check the problem against three filters. Frequency: does it recur weekly or daily? Rare problems struggle to support a subscription. Cost: does it consume hours, lose revenue, create errors or carry compliance risk? Mild annoyances rarely open wallets. Existing effort: are people already doing something manual, messy or expensive to cope? Effort already spent is the earliest sign of willingness to pay.

Example. A founder wants to build “an AI scheduling assistant for clinics”. Restated as a problem: “Independent physiotherapy clinics lose booked appointments every week because reminders are sent manually by reception staff, and patients who forget simply do not show up.” Now there is something to test: do clinics really send reminders manually, how many appointments are lost, and what does a missed appointment cost them?

Pass signal: You can write the problem sentence completely, with a named customer, a concrete cost and a workaround people use today — and you can point to at least one real conversation, post, review or observation where that problem shows up without you prompting it.

Fail signal: The sentence only works in solution language (“people need a smarter tool for…”), or you cannot name a single real person who has the problem. Go back to idea selection rather than forcing this one forward.

Step 2: Define one specific first customer

“Small businesses”, “freelancers” and “marketers” are not customers you can interview — they are categories. Validation needs a first customer narrow enough that you can list actual people, find where they gather, and recognise their version of the problem when they describe it. You can widen later; you cannot validate in the abstract.

How to do it:

1. Write an ideal customer profile (ICP) with five fields: role (who feels the pain, and in B2B, who would approve a purchase — often two different people), company size and type, tools they already use for the job today, trigger events that make the problem urgent now (a new hire, a busy season, a deadline, a tool being discontinued), and where they gather (specific communities, associations, newsletters, LinkedIn groups, local networks).
2. List 20 real people or companies that match the profile, by name. This list is your interview pipeline for Step 3 and your first traffic source for Step 5, so build it now.
3. If you are a solo founder, keep the segment small on purpose. The constraints are different when one person has to find, interview and later support every customer — the narrower starting niches in our guide to micro SaaS ideas built for one-person businesses show the scale that tends to work.

Example. Instead of “clinics”, the founder from Step 1 defines: “Owner-managed physiotherapy practices with 2–8 practitioners, using paper diaries or a basic booking tool, where the owner still handles reminders personally.” Twenty such practices in two cities can be named and approached. That is a testable market.

Pass signal: A written ICP plus a list of at least 20 named people or companies that match it, and at least one channel where you can realistically reach them this week.

Fail signal: You cannot name 20 prospects, or the only way to reach them is “run ads and hope”. Either the segment is too vague or it is a segment you have no access to — both are cheaper to discover now than after a build.

Step 3: Interview customers about past behaviour

Interviews are the highest-value step in this guide and the one most founders do badly, because they pitch instead of asking. The goal of a validation interview is not feedback on your idea. It is facts about the customer’s life: what happened the last time the problem occurred, what they did, what it cost, and what they have already tried.

The best-known guide to doing this well is Rob Fitzpatrick’s The Mom Test, whose official site summarises its core idea as asking questions so good that even your mother could not lie to you with a polite answer (momtestbook.com). Its three rules are worth taping to your monitor: talk about their life instead of your idea; ask about specifics in the past instead of opinions about the future; talk less and listen more.

How to do it:

1. Recruit honestly. Message people from your Step 2 list and ask for 20 minutes to learn how they handle the problem area. Say you are researching, not selling. Warm introductions and community members who have posted about the problem convert better than cold pitches, but even a short, specific cold message works if it names their situation precisely.
2. Ask about the past. Use questions like these, in your own words:
   • “Walk me through the last time this happened. What did you do, step by step?”
   • “What was the hardest or most annoying part of that?”
   • “How often does this come up — weekly, monthly?”
   • “What do you use to handle it today? What have you tried before, and why did you stop?”
   • “What does this problem cost you — in time, money, or hassle?”
   • “Who else is affected by it? Who would decide on paying for a fix?”
3. Never ask these: “Would you use a tool that…?”, “Do you think this is a good idea?”, “How much would you pay for…?” Hypothetical questions produce hypothetical answers, and people are genuinely poor at predicting their own future purchases.
4. Take notes on facts, not compliments. After each call, record: the exact words they used for the problem, how often it happens, what they currently spend in money or hours, and whether they agreed to a next step (a follow-up call, an introduction, seeing an early version). That last item is the strongest interview signal, because it costs them something.
5. Do enough of them. A practical working range is 10–15 interviews with people who match your ICP. Fewer than that and you are reading anecdotes; when the same problems, workarounds and phrases start repeating across calls, you have the pattern you need. If every interview surfaces a completely different problem, your Step 2 segment is too broad — narrow it and continue.

Example. The clinic founder interviews 12 practice owners. Nine describe missed appointments as a weekly problem, seven already pay a staff member to phone patients the day before, and four ask, unprompted, “when could we try it?” That is a pattern. If instead only two mention no-shows and the rest complain about insurance paperwork, the real problem is elsewhere — and the founder has just saved a build.

Pass signal: A clear majority of interviewees describe the same problem as frequent and costly, unprompted, in similar words — and several agree to a concrete next step.

Fail signal: People are polite but vague, describe the problem as occasional or minor, or only engage when you pitch the solution. Politeness is not a weak pass; it is a fail wearing a smile.

Step 4: Check existing demand and alternatives

Interviews tell you how a handful of people experience the problem. This step checks whether the wider market behaves the same way, and what your idea would really be competing against — including the competitor most founders forget: doing nothing.

How to do it:

1. Search demand. List the phrases your customer would type when the problem bites: problem phrases (“how to reduce missed appointments”), solution phrases (“appointment reminder software”), and comparison phrases (“[competitor] alternative”). Check them in a keyword tool such as SEMrush, Google Keyword Planner or Ubersuggest, and read Google autocomplete and “People also ask” for real phrasing. For a narrow B2B niche, modest volume on a high-intent phrase can still be a healthy sign — what matters is that the searches exist and match the problem. Low volume is not an automatic fail, but it tells you early distribution will have to come from outreach and communities rather than search.
2. Community evidence. Search the communities from your Step 2 profile for your problem keywords. Threads that start with “Is there a tool that…”, “How do you handle…” or “I hate doing…” are people raising their hands. Save the links, count how often the topic recurs, and note the exact language — it becomes your interview material and, later, your landing page copy. The people who posted are also prime interview candidates.
3. Map the alternatives. List three kinds of competition: direct (tools solving the same problem for the same customer), indirect (general tools people bend into the job, like spreadsheets, email or a CRM’s side feature), and the status quo (manual work or doing nothing — the option you will actually lose to most often). For each direct alternative, note its target customer, price and positioning.
4. Mine the complaints. Read the negative and middling reviews of direct competitors on review sites and in community threads. Repeated complaints — too complicated, too expensive for small teams, a missing integration, poor support — are a free map of unmet needs and the most credible source of your differentiation.
5. Name your wedge. Write one sentence: “For [ICP], unlike [main alternative], this will [specific difference that matters to them].” If the sentence comes out as “cheaper and easier to use”, keep digging — that is what every challenger claims.

This step applies with extra force to fashionable categories. A long list of AI SaaS ideas worth building can look exciting, but AI features are now cheap to add to almost any product, so “it uses AI” is not a wedge. The wedge has to be the customer, the workflow or the distribution — and the alternatives map is where you find out whether one exists.

Example. The clinic founder finds reminder features inside two large practice-management suites, both aimed at bigger clinics and priced accordingly, plus a stream of reviews from small practices calling them overbuilt. The wedge writes itself: reminders only, set up in an afternoon, priced for a five-person practice.

Pass signal: You can point to real searches, threads or reviews where people ask for help with this problem, and you can name at least five alternatives (including the status quo) plus a one-sentence wedge.

Fail signal: No one is searching, posting or reviewing anything in this space and your interviews were lukewarm. An empty market plus weak interviews usually means no market — not an untapped one. Note that competitors existing is normally a good sign: it proves people already pay to solve the problem.

Step 5: Run a landing page smoke test

A smoke test offers a product that does not exist yet — honestly, as early access — and measures what visitors do. It converts the opinions of Step 3 into behaviour from people who have never met you and owe you no politeness.

How to do it:

1. Build one page, in a day, with a page builder or a simple static site. It needs five things: a headline that names the customer and the outcome (use the words your interviewees used), two or three short paragraphs on the problem and the promised result, who it is for, a price or price range if you have one in mind (testing a price teaches you more than hiding it), and one call to action — join the early-access list, book a short call, or reserve a founding spot. State plainly that the product is in development and what happens next. Deceiving visitors into thinking a finished product exists damages trust and your data.
2. Decide your threshold before you send traffic. Write down, in advance, the result that would count as a pass for you — for example, a target number of signups or booked calls from a defined number of targeted visitors, over a defined period. The exact numbers depend on your market and traffic source, which is why you must set them yourself, before you see the results. A threshold invented afterwards to fit disappointing numbers is how weak ideas get built.
3. Send targeted traffic, not random traffic. Share the page where your Step 2 customers already are: the communities you researched in Step 4, direct messages and emails to your prospect list, relevant newsletters or partner audiences, or a small, tightly targeted ad test if your budget allows. A page nobody visits proves nothing either way.
4. Read the result properly. Separate three numbers: visitors, call-to-action clicks, and completed signups or bookings. Clicks with no completions usually mean the offer got interesting but the ask felt too big or unclear; decent traffic with almost no clicks usually means the headline problem is not resonating — which may be a messaging problem or a problem problem, and your interview notes will help you tell which.

Example. The clinic founder builds a one-page site over a weekend, posts it in two practice-owner communities and emails the 20 practices from the Step 2 list. She had written down her pass mark in advance: at least 8 of those 20 practices joining the early-access list or booking a call. The result decides whether she proceeds to Step 6 — not her mood on the day.

Pass signal: The page meets the threshold you set in advance, from visitors who match your ICP — and signups keep coming, or reply to follow-up, rather than evaporating.

Fail signal: Well-targeted traffic arrives and almost nobody acts, or signups come only from friends and fellow founders outside the ICP. Retest once with a sharper headline drawn from interview language if you believe the message was off; if it fails again, believe it.

Step 6: Ask for a real commitment

This is the step that separates validated from merely interesting. Everything before it measured attention and opinion. Now you ask the people who showed intent to give you something scarce: money, a signature, or a scheduled place in their working week.

How to do it, in ascending order of strength:

1. A booked follow-up with a date. “I’ll show you the first version on Tuesday — does 10am work?” A calendar entry is a small but real cost.
2. A letter of intent (LOI) or pilot agreement. For B2B ideas, a short, non-binding letter stating the problem, the intent to trial the product when available, and the price discussed. It costs the signer internal effort, which is exactly why it counts.
3. A refundable deposit or pre-order. Put a payment link on your smoke-test page or send it to your warm list: a founding-member deposit, clearly described as refundable if you do not build. A payment is the strongest pre-build signal available, and it comes with an obligation — communicate honestly and refund promptly if you stop.
4. A paid pilot or manual first delivery. Sell the outcome before the software exists and deliver it by hand: you, a spreadsheet, forms and email, openly described as an early, manual service. Paul Graham’s classic essay on early-stage startups, “Do Things That Don’t Scale”, makes the underlying case — at the start, doing unscalable work for individual customers is how you learn what is actually worth automating. A manual pilot shows you which steps customers value, which you can skip, and what your first version must contain.

Set your commitment target in advance, as you did in Step 5 — for example, a specific number of deposits, LOIs or paid pilots from your target segment, with at least some of them from people who are not friends or existing contacts. One enthusiastic friend is a favour; three strangers committing is a market signal.

Example. The clinic founder offers five pilot places: she will run reminders manually for a month for a small fixed fee, credited against the first subscription if the product launches. Three practices pay. She now has revenue, three customers’ real workflows to learn from, and a concrete reason to build — in that order.

Pass signal: You hit the commitment target you set in advance, from ICP customers, without discounting the offer into meaninglessness or relying on personal favours.

Fail signal: People who praised the idea go quiet when money, a signature or a date is requested. That gap between words and commitment is the single most useful piece of data in this entire guide — it means the problem is not painful enough, the price is wrong, or you are talking to the wrong customer. All three are fixable; building anyway is not.

Step 7: Score the evidence and decide — build, pivot or park

Validation that does not end in a written decision was just research. Gather everything into the scorecard below, score it honestly, and commit to one of three verdicts.

The three verdicts:

• Build — the evidence passed your thresholds: the problem is frequent and costly, customers are reachable, and real commitments exist. Build the smallest version that serves the customers who committed, starting with the workflow they paid for. Nothing more.
• Pivot — the problem is real but something specific failed: the segment was wrong (a neighbouring group described the pain more strongly), the price was wrong (interest at one price, silence at another), or the wedge was wrong (people wanted a different outcome than the one you offered). Change one variable, re-run the relevant steps, and score again. Changing everything at once teaches you nothing.
• Park — the signals failed across interviews, demand checks and commitment. Write down what you learned, keep the interview notes and the prospect list (they are valuable for the next idea), and move on. Parking an idea at the cost of a few weeks is the process working, not failing.

Whichever verdict you reach, write it down with the evidence behind it and a date. Memory edits itself over time, and a written verdict is what stops you quietly resurrecting a parked idea — or abandoning a validated one — three months later.

Pass signal (to build): Your scorecard total (below) is in the build range and Step 6 produced at least the minimum commitment you set in advance. Both conditions, not either.

Fail signal: You find yourself arguing with your own scorecard. That argument is the answer.

Validation methods compared

The steps above combine several methods. This table summarises what each one costs, how fast it runs, and how much you should trust what it tells you — so you can choose the right test for your situation (and see why the strongest validation stacks several together).

Method	Typical cost	Speed	Strength of signal	Best for	Watch out for
Customer interviews	Your time only	Days to 2 weeks	Medium — strong on problem truth, weak on willingness to pay	Learning whether the problem is real, frequent and costly, and hearing the customer’s own words	Polite, biased answers if you pitch or ask hypothetical questions
Landing page smoke test	A page-builder plan or a domain you already own; a day to build	Days	Medium — real behaviour, but only measures interest in the offer as written	Testing whether your problem and message convert strangers, not just contacts	No traffic, or off-target traffic, makes the result meaningless either way
Waitlist	Included with the smoke test page	Days to weeks	Weak to medium — an email is cheap to give	Building a launch audience and identifying people to interview and sell to	Counting signups as validation on their own; signups measure curiosity, not commitment
Letter of intent (LOI)	Your time; sometimes a template reviewed properly	1–3 weeks	Strong for B2B — the signer spends internal credibility	Testing budget-holder intent for higher-priced B2B products before building	Non-binding by design; an LOI from someone without budget authority counts for little
Paid pilot / pre-sale	Payment tooling you likely already have; your delivery time for manual pilots	1–4 weeks	Strongest available before building — money changes hands	Proving willingness to pay and learning the real workflow by delivering manually	You owe delivery or a refund; be explicit that the product is early or not yet built

Read the table as a ladder: each rung costs the customer more, and therefore tells you more. Weak signals are fine for early steps — they are how you earn the right to ask for strong ones.

Copyable SaaS idea validation checklist and scorecard

Copy this into your notes app or a document and work through it for one idea. Score each item 0 (no evidence), 1 (some evidence) or 2 (strong evidence) as honestly as you can.

SAAS IDEA VALIDATION SCORECARD — Idea: ____________  Date: ________

PROBLEM
[ ] Problem written in one sentence, without naming the product      /2
[ ] Problem is frequent (weekly or more) for the target customer     /2
[ ] Problem has a clear cost in time, money or risk                  /2
[ ] Customers already cope with a workaround or spend money today    /2

CUSTOMER
[ ] ICP written down: role, company size/type, tools, triggers      /2
[ ] 20+ real prospects named, with a channel to reach them           /2
[ ] In B2B: both the user and the budget approver identified         /2

INTERVIEWS
[ ] 10–15 interviews done with people matching the ICP               /2
[ ] Questions asked about past behaviour, not future intentions      /2
[ ] Same problem described unprompted, in similar words, by most     /2
[ ] Several interviewees agreed to a concrete next step              /2

DEMAND AND ALTERNATIVES
[ ] Real search queries / community threads about the problem found  /2
[ ] 5+ alternatives mapped, including the status quo                 /2
[ ] Competitor complaints mined; a one-sentence wedge written        /2

SMOKE TEST
[ ] Landing page live with one clear offer and one 
call to action    /2
[ ] Pass threshold written down BEFORE traffic was sent              /2
[ ] Targeted ICP traffic sent; the threshold was met                 
/2

COMMITMENT
[ ] A specific commitment was asked for (deposit, LOI, paid pilot)   /2
[ ] Commitment target met, incl. people who are not friends          /2
[ ] Price discussed or tested openly, not avoided                    /2

TOTAL: ____ / 40

DECISION BANDS (guidance, not a formula)
28–40  Build — provided the Commitment section scores at least 4.
18–27  Pivot — find the lowest-scoring section, change one variable,
       and re-run those tests before deciding again.
0–17   Park — the evidence is not there. Record what you learned
       and move to the next idea.

Two rules for using the scorecard. First, the commitment section is a gate, not just points: a high total with a zero on commitment means people like the idea but will not pay for it, which is a pivot or a park, not a build. Second, rescoring the same evidence more generously a week later is not progress — only new evidence moves a score.

Common validation mistakes to avoid

1. Asking “would you buy this?” People answer the person, not the question. Ask what they did last time instead, and watch what they commit to.
2. Validating with friends, family and fellow founders. They are accessible, encouraging and almost never your market. Their praise is the most dangerous data in the process.
3. Pitching during interviews. The moment you describe your solution, the conversation stops producing facts about their problem and starts producing reactions to your pitch. Save the reveal for the very end, if at all.
4. Treating waitlist signups as proof of demand. An email address is curiosity. Signups are the start of a conversation that ends at commitment — or does not.
5. Skipping the status quo. Your biggest competitor is the spreadsheet, the manual routine, or doing nothing. If your idea is not clearly better than free-and-familiar, it will lose to it.
6. Building an “MVP” that is really version one. If the first build takes months and includes accounts, dashboards and settings, it is not a validation tool any more. The manual pilot and the single-workflow first version exist precisely to keep this small.
7. Validating the solution instead of the problem. Features are easy to change; a problem nobody has is not. Every test in this guide is ordered problem-first for that reason.
8. Never setting a kill threshold. If no possible result would make you stop, you are not validating — you are looking for permission. Write the pass marks down before each test, as Steps 5 and 6 insist.

Frequently asked questions about how to validate SaaS ideas

How long does it take to validate a SaaS idea?

For most solo founders and small teams, the seven steps fit into roughly two to four weeks of part-time work — if you can reach your target customers quickly. Interviews and the commitment ask are where the calendar goes; recruiting people is slower than running the tests. If a month passes and you still cannot get ICP customers into conversations, treat that itself as a finding: a customer you cannot reach to interview is a customer you cannot reach to sell to.

How many customer interviews do I need?

Start with 10–15 interviews with people who match your target customer profile. That range is usually enough for the same problems, workarounds and phrases to start repeating, and repetition is the signal that you have the pattern. Fewer than ten is anecdote. If you are past twenty and still hearing a brand-new problem in every call, the issue is almost certainly your segment, not your sample size — narrow the customer definition and run a shorter second round.

Can I validate a SaaS idea without building anything?

Yes — that is the point of the process. Steps 1–6 require no product code at all: a document, a page builder for the smoke test, and a payment link for deposits are the whole toolkit. Even Step 7’s “build” verdict should start with the smallest possible version, and a paid manual pilot (Step 6) can run a real service for real customers before any software exists.

Is a waitlist enough validation on its own?

No. A waitlist proves that your message made some people curious, which is worth having — those people are your first interview and pilot candidates. But an email address costs nothing to give, so it cannot tell you whether anyone will pay. A waitlist becomes meaningful evidence only when a reasonable share of it converts to the next, costlier step: a booked call, a deposit, or a pilot.

What if there are no competitors for my idea?

Treat it as a question, not a trophy. Sometimes you have genuinely found an opening — a new technology or a newly reachable niche. More often, an empty field means the problem is not painful enough for anyone to have bothered, or the “competition” is a workaround you have not noticed yet (a spreadsheet, an assistant, an existing tool’s side feature). Your interviews decide which it is: if customers describe a frequent, costly problem and are actively improvising solutions, the opening may be real. If they shrug, believe them.

How much does it cost to validate SaaS ideas?

It can be done for close to nothing beyond your time. Interviews are free, a smoke-test page needs little more than a page-builder plan or a domain you already own, and community research costs attention rather than money. The optional extras are a small, tightly targeted ad test to drive smoke-test traffic and payment tooling for deposits, which typically uses an account you may already have. The real budget is your hours — which is exactly why validation is cheap compared with the alternative of building first.

Conclusion: validate first, then build the smallest thing

Learning how to validate SaaS ideas comes down to one habit: never let an idea consume build time before it has survived contact with customers. Write the problem in one sentence. Name one specific customer. Interview them about the past, not the future. Check that demand and alternatives exist. Smoke-test the offer, then ask for a commitment that costs something. Score it, write the verdict down, and honour it.

If your verdict is “build”, you now know things most founders guess at: which customer to build for, which workflow matters first, what words they use for the problem, and what a fair first price looks like — and if you are building lean as a solo founder, the shortlist of micro SaaS ideas for solo developers is a good place to compare your validated idea against neighbouring opportunities. If your verdict is “pivot” or “park”, you have bought that knowledge for a few weeks of conversations instead of months of development — and your interview notes and prospect list carry straight over to the next idea on your list.

Your next step takes an hour: open a document, write your Step 1 problem sentence, and list the assumptions you cannot yet fill in. Those gaps are your validation plan.