Validate a Startup Idea Before Building
Validate a startup idea by defining a specific buyer and buying trigger, observing a recent problem, documenting the current alternative, and testing a concrete commitment. Use the evidence to build a limited next version, narrow the segment or offer, or stop the hypothesis. A positive interview alone does not establish that a customer will buy.
A founder deciding whether to build needs evidence about a purchase: who has the problem, what happens when it remains unsolved, and what that person can commit. A pitch that gets compliments leaves these questions open. A useful validation test makes one uncertain assumption observable and ties the result to a development decision.
The method below is an editorial recommendation for an early B2B idea. It produces a decision record that a cofounder can inspect. It does not establish market size or predict startup success. Use it before spending heavily on development, and repeat it whenever the target buyer changes.
Define the buying situation before designing the product
Write a short hypothesis describing a customer, a recurring task, a buying trigger, the current alternative, and a person who can authorize spending. Each element should be specific enough to check in a conversation. A broad category such as small businesses hides different budgets and workflows.
For example, a delivery operator opening a new depot may need to schedule drivers quickly. A stable operator may tolerate the same scheduling process for years. The workflow looks similar, but the reason to buy now differs. Recruit people who match the situation you intend to serve, including the trigger.
Daniel Tonkopiy's published GTM method starts with a narrow customer profile, a buying trigger, and a decision-maker, then uses researched accounts and objections to refine the offer. For validation, turn those choices into claims that a customer can confirm or contradict.
Separate market context from evidence about a particular buyer
The SBA's business planning guidance recommends examining demand, market size, competition, location, and prices paid for alternatives. Use that research to understand the setting. Direct research can then answer questions about the workflow and purchasing process of the segment you selected.
List the alternatives a buyer can actually choose: software, an employee, an agency, a spreadsheet, or leaving the task unfinished. Check how each fits the workflow and who approves its cost. An apparently empty software category may already have a workable human solution. Record the effort of switching as well as the shortcomings of the current approach.
Ask about the last occurrence of the problem
Start the interview with a recent event. Ask what triggered the task, who handled it, which tools they used, and where time or money went. Request a walkthrough of an existing artifact when appropriate: a blank form, an anonymized schedule, or a process diagram. Obtain permission and avoid collecting customer secrets that the test does not require.
Y Combinator's user observation guide recommends defining the observation goal and distinguishing a user's pain, need, and proposed solution. It also highlights that the user and customer can be different people. Use that distinction when the person doing a task cannot authorize the purchase.
Keep the product pitch for later. Questions about a hypothetical purchase invite speculation. Questions about the last failed handoff or recent invoice give the founder something to examine. After the walkthrough, ask who felt the consequences, whether anyone tried to fix them, and what prevented a change.
Use a worksheet that preserves contradictions
Fill in this worksheet for each account before combining the notes. Keep the customer's observed behavior separate from the founder's interpretation. Blank cells identify the next question. A negative answer belongs in the record alongside encouraging evidence.
| Question | Evidence to capture | Decision it informs |
|---|---|---|
| What happened recently? | A dated event and the workflow involved | Whether the problem is active |
| What does the buyer use today? | The current tool, service, or manual process | What the product must replace |
| Who bears the cost? | The affected role and a stated operational consequence | Which person needs the outcome |
| Who can authorize spending? | The budget owner and approval steps | Whether the offer can be purchased |
| What makes a change timely? | A deadline, contract event, or operational trigger | Which accounts to approach first |
| What will the customer do next? | An agreed action, owner, and date | Whether to invest in a pilot |
| What weakens the hypothesis? | A satisfactory alternative or a failed commitment | Whether to narrow or stop |
Test a commitment with the smallest honest offer
Choose a next step that exposes the assumption carrying the most risk. A workflow prototype can test usability. A conversation with the budget owner can test purchasing access. A paid manual pilot can test whether the outcome is valuable enough to buy. None answers every question, so write down what the test leaves unresolved.
Describe the scope, delivery date, customer responsibilities, price, and success condition before asking for a commitment. Disclose manual work and unfinished capabilities. A pilot that depends on unlimited founder labor can validate demand for a service while leaving software economics uncertain. Record that distinction in the decision.
For an enterprise buyer unable to purchase immediately, identify a concrete approval step: a security review, an internal sponsor meeting, or access to an authorized test dataset. A signed expression of interest still needs scrutiny. Check whether it carries a real obligation, who signed it, and what must happen before money changes hands.
Worked B2B example: depot scheduling
Hypothetical example: a founder proposes scheduling software for delivery companies. All account counts, prices, and outcomes in this example are invented to illustrate the decision process. They are neither customer results nor recommended performance benchmarks.
The founder interviews six operators: three opening depots and three running established sites. The established sites have workable scheduling routines. Two expanding operators describe late driver assignments during depot openings. Their operations managers feel the problem, but regional directors control spending. The founder narrows the hypothesis to depot openings and requests introductions to those directors.
The revised offer is a two-week, $500 manual scheduling pilot for one depot. The customer supplies authorized staffing inputs. The founder agrees to deliver a usable schedule and track correction requests. One director approves the paid pilot; the other postpones the project because the opening date moved.
That result supports serving one real workflow, with one purchasing path. It leaves retention, repeatability, and software costs unknown. The founder runs the pilot, measures delivery effort, and checks whether another comparable depot will buy the same scope. Building a general platform at this point would require evidence the test has yet to produce.
Make a build, narrow, or stop decision
Build a limited next version when the records show a recurring problem in the chosen situation, access to a buyer, and completed commitments consistent with the offer. Name the remaining uncertainty and limit development to what tests it.
Narrow the segment or offer when evidence clusters around a particular trigger, role, or task. Specify the changed hypothesis and recruit against it. Keep the earlier records so the team can explain why the focus changed.
Stop this hypothesis when observed consequences are minor, available alternatives satisfy the buyer, or the proposed offer cannot survive the approval process and delivery costs. Missing interview access alone leaves the question unresolved. Diagnose access before treating silence as proof that demand is absent.
End with a written decision: what the evidence supports, what remains unknown, the next action, its owner, and the spending limit. Set the review date before doing the next test. This keeps validation connected to an investment decision instead of becoming an endless collection of interviews.
Bring the completed worksheet and the contradictory evidence to a Startup Mentor strategy session to review the segment, offer, and next test.
Frequently asked questions
Can a startup idea be validated before building an MVP?
Customer observation, interviews with budget owners, and a clearly scoped manual pilot can test parts of the idea before a software MVP exists. Choose the method according to the uncertain assumption. These tests leave technical feasibility and production costs to be evaluated separately.
How many customer interviews are enough to validate an idea?
There is no interview count that proves a startup will succeed. Define the decision the research must support, recruit customers who match the intended buying situation, preserve contradictory evidence, and test behavior beyond an interview. The next investment should match the strength and limits of the evidence.
Does a letter of intent prove that a customer will pay?
A letter of intent can document interest, but its significance depends on the signer, obligations, approval process, and conditions. Check what the customer must do next and whether that action happens. A paid pilot provides evidence about a purchase while still leaving repeatability and retention unresolved.
What should a founder do when validation results are mixed?
Compare results by buying trigger, customer role, and current alternative. Narrow the hypothesis if the evidence points to a particular situation. If access to the right people failed, improve recruitment before interpreting silence as lack of demand. Record what remains unknown and limit the next investment.