An attractive idea is a starting hypothesis. Before building a full product or service, test whether a defined customer has the problem, values the proposed change and can be served on workable terms. Good validation produces a decision, including permission to stop when the evidence does not support further investment.
Write A Falsifiable Offer Hypothesis
Describe one customer group, the situation that creates the need, the promised outcome and the delivery method. State the important assumptions: who decides, how the purchase is funded, what the customer must provide and which resources delivery consumes.
For an illustrative business serving property managers, a new maintenance coordination service might depend on managers needing outside scheduling help and being able to authorize recurring spend. Those are separate assumptions. Interest from an employee who cannot authorize the purchase does not validate both.
Learn About Existing Behavior
Ask prospective users how they handle the problem today, what happens when it remains unresolved and when they last tried to change it. Ask buyers how they evaluate and approve a purchase. Look for evidence of effort, cost or a recent decision instead of relying only on reactions to your idea.
Avoid questions that encourage politeness. Would this be useful is weaker than a discussion of an actual workflow and its consequences. Keep notes of disconfirming evidence, including reasons the customer might reasonably keep the current approach.
Choose The Smallest Honest Test
Possible tests include a specific proposal, a limited manual service or a prototype demonstration. Make the offer’s current state clear. If a capability is a concept, say so; if delivery is limited, explain the limit before seeking a commitment.
Choose a signal proportionate to the purchase. A signed pilot agreement may provide useful evidence for a complex service; a qualified introduction to the budget owner may be an earlier signal. A casual expression of interest should not be labeled a sale.
Test Delivery And Economics Together
Record the labor, coordination, support and rework required to fulfill the pilot. Check whether the customer’s expected outcome matches what the team can deliver. Include dependencies on specialists, suppliers and existing business capacity.
Separate learning costs from recurring delivery costs, but do not assume every difficult part will disappear at scale. Identify what a repeatable version would actually require and which assumptions remain untested.
Set Continue, Revise And Stop Conditions
Before the test, define the evidence needed for the next investment. Include buyer commitment, delivery feasibility and acceptable economics. There is no universal sample size or conversion threshold for every offer; choose a standard that reflects the risk and decision.
Continue when the agreed evidence supports the next step. Revise when a specific assumption fails but a credible alternative remains. Stop when the need, authority or delivery model does not justify further investment. VG can help structure the experiment and keep the decision grounded in what the test actually showed.
Common Questions
Do We Need To Build Software To Validate A Software Idea?
Not always. A clearly disclosed prototype or manual service can test parts of the need and workflow. It cannot prove the technical feasibility, security or operating cost of the eventual software.
Does One Paying Customer Prove Product-Market Fit?
One customer provides evidence about that purchase and delivery experience. Broader demand, repeatability and economics still need investigation before drawing a larger conclusion.