Product validation before you build: a five-test process

Product validation is the work of reducing the biggest risks in an idea before you invest heavily in it.

It is not asking friends whether the idea sounds good. Compliments are cheap. Validation comes from specific behavior: people describe the problem without prompting, use a rough solution, give up something valuable, or return after trying it.

1. Validate the customer

Define who has the problem narrowly enough to find them.

“Small businesses” is too broad. “Agencies with five to twenty employees that send client reports every week” gives you a group to interview and a workflow to observe.

Talk to at least five people in that group. If their situations differ completely, narrow the segment again.

2. Validate the problem

Ask about the last time the problem happened:

• What triggered it?
• What did you do?
• How long did it take?
• Who else was involved?
• What was the consequence?

Avoid pitching your solution during this conversation. You are looking for current evidence, not a polite reaction to a hypothetical product.

3. Validate demand

Strong demand has a cost attached. The customer already spends time, money, reputation, or effort on a workaround.

Useful signals include:

• A spreadsheet maintained every week
• A contractor hired for the task
• Several tools connected awkwardly
• A delayed sale or project
• A willingness to join a paid pilot

A waitlist email is weaker evidence than a customer changing behavior.

4. Validate the solution

Test the smallest version that answers the risky question.

Use a prototype when usability is uncertain. Deliver the result manually when you need to test value. Build a narrow working version when reliability or integration is the risk.

Measure whether people complete the intended job, not whether they say the design looks good.

5. Validate the business

A useful solution still needs a workable business.

Check whether you can reach customers, charge enough, support them, and deliver the result repeatedly. Record the assumptions and the evidence for each.

Keep a validation log

For every test, write:

Assumption:
Test:
Success signal:
Result:
Decision:

This prevents the team from changing the definition of success after seeing the outcome.

Product validation does not remove uncertainty. It makes the next investment proportional to the evidence.

Feedboard helps you collect early feedback, group repeated problems, and keep potential users updated as the product develops. Start a feedback board.

Use an evidence ladder

Different signals reduce different amounts of risk:

1. Opinion: someone says the idea sounds useful.
2. History: they describe a recent problem and workaround.
3. Commitment: they give time, data, access, or money to test.
4. Use: they complete the job with a prototype or manual service.
5. Repetition: they return and use it again.
6. Business evidence: acquisition, delivery, and support are sustainable.

Move investment up as the evidence becomes stronger. A landing-page signup can justify interviews, not a year of engineering.

Write assumptions by category

Customer

The chosen segment experiences the problem and can be reached.

Problem

The problem is frequent or costly enough to motivate change.

Solution

The proposed approach helps customers complete the job.

Usability

Customers can understand and use the workflow.

Business

They will pay enough, acquisition is viable, and delivery can scale.

Feasibility and risk

The product can be built securely, legally, and reliably.

Rank assumptions by how fatal and uncertain they are. Test the riskiest one first.

Choose the smallest valid test

Risk	Useful test
Customer exists	Recruiting experiment and interviews
Problem matters	Recent-event interviews and workaround review
Demand exists	Paid pilot, deposit, or concrete commitment
Workflow works	Clickable prototype or concierge service
Repeated value	Limited working product used over time
Acquisition works	Small channel test with conversion tracking
Price works	Real offer to qualified buyers

A test should create evidence relevant to the assumption. Social-media likes do not validate retention.

Worked example

A founder believes agencies need automated client-status reports.

The first interviews show agencies already build reports manually every Friday. Five agree to share their current template. Three join a concierge pilot where the founder produces the report from exported data.

Two clients read the reports, but account managers spend most time correcting project names. The riskiest problem is now data cleanup, not email scheduling.

The founder prototypes mapping rules before building a scheduling engine. After customers successfully reuse mappings for four weeks, the team builds the narrow workflow.

Validation changed the solution while strengthening evidence for the problem.

Define success before the test

Use:

Assumption:
Population:
Test:
Success threshold:
Guardrail:
Time window:
Result:
Decision:

For example:

At least five of eight agency administrators will schedule a second weekly report within thirty days, with fewer than one manual correction per report.

Do not change the threshold after seeing results.

Learn from weak results

A failed test can mean:

• The segment was wrong.
• The problem was mild.
• The solution was confusing.
• The value appeared too slowly.
• The price or buying process failed.
• The test did not represent the real workflow.

Name which explanation the evidence supports and run the next smallest test. Do not restart with a completely different idea without recording what was learned.

Validate willingness to pay

Price surveys are weak when no purchase is possible. Use real offers with clear scope, terms, and customer support.

For early B2B products, paid pilots can test budget, buying process, delivery cost, and value. Avoid custom promises that turn every pilot into a different service.

Protect research quality

Recruit outside friends and existing fans. Include people who tried alternatives, abandoned the workflow, or decided the problem was not worth solving.

Keep interview notes separate from interpretation. Look for evidence against the idea, not only confirmation.

Know when to stop validating

Validation never produces certainty. Move forward when the next test requires a working product and the evidence justifies the cost.

Stop or change direction when the problem is weak, the target group cannot be reached, commitments do not materialize, or delivery economics remain unsustainable.

Frequently asked questions

How many interviews are enough?

Enough to make the current decision. Five focused interviews may reveal obvious workflow patterns; market conclusions need broader evidence and behavior.

Is a waitlist validation?

It shows some message-level interest. Strengthen it with interviews, commitments, and actual use.

Can an existing product validate with feature flags?

Yes. Release to a selected segment, define success and guardrails, and compare behavior with an appropriate baseline.

Does validation end after launch?

No. Each major roadmap bet contains new assumptions. Continue with usage, feedback, experiments, and business results.

Maintain a validation register after launch. Link every major assumption to its latest evidence, owner, review date, and decision. This prevents old launch beliefs from becoming permanent product facts after the market or customer changes.