Before you build the product, find out whether the problem deserves one.
A compelling idea is a starting point. Validation is the work of turning its weakest assumptions into observable evidence: who experiences the problem, what it costs them, whether they can buy, and what they actually do when offered help.
Set a clear learning goal, a small budget and a date to review what you learn.
Validation
Start with one buyer.
A narrow customer gives your first test a clear meaning.
“Small businesses” is too broad for a useful first experiment. Choose a job, a situation and a trigger: a two-person podcast agency onboarding its third client, for example. That gives you a place to look, a workflow to observe and a person who might own the budget.
Write a one-sentence hypothesis: When [buyer] encounters [trigger], they struggle with [task], causing [consequence]. Keep the solution out of this sentence. If the problem only makes sense once you describe your app, you may be starting from a feature rather than a need.
- User
- Who does the work and feels the friction?
- Buyer
- Who approves the purchase or can spend without approval?
- Reach
- Where can you meet these people without buying a huge audience?
- Trigger
- What recent event makes this problem urgent?
Your first artifact
A short buyer brief with one role, one workflow and one consequence. List a handful of people you can realistically contact. If you cannot reach them, fix the distribution assumption before building.
For a B2B product, the person who likes the idea may not control the purchase. Ask how new tools are approved, who owns the data and when spending decisions happen. A useful tool can still be a difficult business if access, procurement or onboarding is too expensive.
Validation
Investigate a recent problem.
A specific incident tells you more than a hypothetical compliment.
Invite people to discuss the job they already do. Ask for the last time it went wrong, the steps they took and the workaround they used. Listen for consequences: a delayed invoice, duplicated effort, a missed deadline or a client escalation.
Y Combinator’s guide to user conversations is a useful starting point. Our interview outline below turns that principle into a concrete workflow investigation.
A conversation you can use
Ask: What happened the last time? Can you walk me through it? What did you try? What did that cost in time or money? Who else was involved? What would have happened if you left it unresolved?
With permission, ask to see the relevant spreadsheet, checklist or sanitized example. Do not collect private customer information simply because it is available. A blank template or redacted artifact is often enough to understand the workflow.
Record what the person said separately from your interpretation. “We spent two hours chasing files last Tuesday” is an observation. “They will pay for automated onboarding” is still a hypothesis. Preserve examples that weaken your idea as carefully as the ones that support it.
- Useful signal
- A recurring incident, a costly workaround and an identifiable owner.
- Weak signal
- Praise for a demo, a feature request or a prediction about future use.
- Next question
- Does this pattern repeat among people with the same job and buying context?
Validation
Find the reason to switch.
Your real competitor may be a spreadsheet that already works.
Map the current route from problem to outcome. Include software, manual work, an assistant and doing nothing. The existence of competitors does not disqualify an idea; it tells you what buyers can already choose.
Compare your proposed improvement against the buyer’s actual baseline. A faster task is not automatically a better purchase if it creates a migration project, needs sensitive permissions or adds another inbox to check.
- Current approach
- What do they use today, and what is already good about it?
- Gap
- Which exact step still requires repeated work or creates errors?
- Switching cost
- What data, behavior, approvals or integrations must change?
- Outcome
- Which measurable result would justify trying a new approach?
A concrete switching hypothesis
For the podcast agency, test one outcome: collecting the required client assets with less follow-up. Compare the new process to the existing checklist. Do not claim the whole agency workflow needs replacing.
Choose a wedge you can demonstrate without pretending to have features you do not have. For example, accept a small batch of files through an existing upload service and manually check completeness. If the buyer values the outcome, automation becomes a later implementation choice.
Validation
Test a small, honest offer.
The next step should require more than saying “sounds good.”
Offer one clearly bounded result to the people who described the problem. Name what you will deliver, what is manual, what it costs, when it arrives and what happens if you cannot deliver. A concierge pilot can test the value of the result before you build a software product.
A landing page can help communicate the offer, but email sign-ups alone do not prove willingness to pay. A booked pilot, shared sample, approved budget or payment provides different evidence. State exactly which commitment you are measuring.
An illustrative pilot offer
“I will prepare the onboarding checklist and check the client assets for one new podcast project. You will receive a completeness report and missing-item list by the agreed date. This is a manual pilot, not an automated platform.” Agree the price and scope with the buyer before accepting the work.
Use a truthful call to action such as “Apply for a pilot” or “Book a walkthrough.” If a feature is not available, say so. An experiment should reveal demand without misleading people about what exists.
Decide the measurement before launching. Record eligible people reached, responses, completed conversations, offers, commitments, delivered outcomes and repeat requests. Track the same buyer segment through the whole funnel; mixing unrelated audiences can make a weak offer look stronger than it is.
Validation
Decide from behavior.
Build the next smallest thing the evidence can justify.
Separate learning into three questions: Is the problem recurring? Does your proposed outcome improve it? Can you deliver that outcome at a cost that leaves room for a business? A first payment helps answer only part of that story.
Choose a small review window and a spending cap before the test. For example, you might run several interviews and a couple of pilots over two weeks. Those are manageable planning targets, not statistical guarantees. A low response rate may reveal the wrong channel rather than an absent problem.
- Continue
- People in the same segment show a repeated problem, try the offer, use the output and want another cycle.
- Refine
- The problem is real, but the proposed workflow, buyer, price or channel is wrong.
- Pause
- You cannot find recurring pain, buyers will not commit, or delivery costs overwhelm the value.
- Build
- Automate the repeated bottleneck you observed. Preserve the useful parts of the manual process.
Keep a decision record
Write the original hypothesis, the test, the observations, the strongest counterexample and the next decision. Include delivery time and support burden. This turns an experiment into accumulated knowledge instead of a story you remember differently later.
After a useful pilot, measure repeat use before expanding the feature list. A buyer who returns for the same job is a more useful signal than a long wish list. Continue talking to users while you build; discovery does not end with the first release.
Intellevate.zip gives this process a much stronger starting point. Instead of brainstorming blindly, you begin with 1,000+ validated, deeply researched SaaS ideas and 59 fields of strategic intelligence per idea. Use your AI assistant to rank opportunities against your skills, buyer access, budget and goals, then apply this execution framework to the ideas that fit you best.
Validation
Questions before you begin.
Keep the standard of evidence clear.
How many interviews are enough?
There is no universal number. Look for a coherent pattern within a specific segment, then test the proposed outcome. A small convenience sample helps you learn; it does not establish population-wide demand.
Do I need to charge for the first pilot?
Payment is useful evidence when it fits the offer, but an early operational pilot may first test feasibility. Keep unpaid and paid results separate. Agree scope, costs and expectations explicitly.
Can I validate with an AI-generated demo?
A demo can help someone understand the workflow. Measure whether they complete a useful task or commit to a real next step, rather than whether they admire the interface.
What should I build first?
Build the smallest repeated step that the pilot showed was valuable. Authentication, integrations and dashboards belong in the first release only when the tested workflow requires them.
Continue with five validated agency micro SaaS opportunities or eight validated productivity SaaS opportunities.