Pre-Build Validation: Test Demand Before You Write Code

Your team can lose months on an idea that customers describe as useful. The warning sign is not criticism. It is polite enthusiasm with no change in behavior: no workflow shared, no buyer involved, and no commitment made.

Pre-build validation should tell you whether software is the next necessary experiment. It cannot establish product-market fit (PMF); only real adoption, repeated use, retention, and continued willingness to choose the product can do that. What it can do is replace a vague bet with an evidence-backed decision about whom to serve, which problem to solve, what outcome to promise, and what must be built first.

Key takeaways

• Pre-build validation earns permission to build. It does not prove product-market fit.
• Start with a narrowly defined customer, a recurring trigger, a consequential problem, and an observable desired outcome.
• Past behavior, current workarounds, shared artifacts, and concrete next steps carry more weight than praise or feature requests.
• Match each prototype to one uncertainty. A concept can test comprehension; a workflow can test usability; a manual service can test whether the outcome matters.
• Willingness to pay becomes credible only when a real buyer considers a specific offer and advances the buying process.
• Build when the most important remaining uncertainty requires a functioning product in the customer’s hands.

Define the evidence you need before you build

I treat pre-build validation as a decision gate, not a claim of PMF. The useful question is not whether people like the idea. It is: What must be true for building this product to be the most sensible next test?

Write the hypothesis before scheduling interviews or drawing screens. A practical version looks like this:

For [specific customer], when [trigger occurs], completing [job] is difficult because [constraint]. They currently use [workaround], which creates [consequence]. A solution that produces [observable outcome] should earn [concrete commitment] from [buyer] through [reachable channel].

Every bracket is an assumption. Validation consists of replacing those assumptions with evidence or discovering that they do not hold.

• Specific customer: Define the segment by its situation, workflow, constraints, and reason for acting. A broad persona such as small businesses or operations leaders hides more variation than it explains.
• Trigger and job: Identify what starts the workflow and what the customer is trying to accomplish. A problem without a recognizable trigger is difficult to find, message, and measure.
• Existing workaround: Look for what people already do, including spreadsheets, manual coordination, another product, an outsourced service, or deliberate inaction. The workaround tells you what your product must displace.
• Consequence: Determine what gets delayed, lost, duplicated, exposed to risk, or made harder. If leaving the problem alone has no meaningful consequence, urgency will remain weak.
• Observable outcome: Describe the changed state, not the feature. Customers buy a completed job, reduced burden, or improved result; they do not buy your roadmap vocabulary.
• Economic actor: Separate the user, champion, buyer, approver, and anyone who can block adoption. In some products one person fills every role. In B2B products they often do not.
• Reachable channel: State how you expect to find qualified customers. A real problem in a segment you cannot identify or reach is not yet a workable market hypothesis.

Adjust the test to the shape of the market

A competitive market and a greenfield market require different proof.

• In a competitive market, existing alternatives indicate that a category and buying behavior may already exist. Your harder questions concern switching: What is broken in the current solution? Why is that gap important now? What cost, migration effort, integration, or trust barrier would stop a change? A list of desired features is not a switching case.
• In a greenfield market, the customer may have a problem without a budget, category name, or familiar buying process. Test whether the customer recognizes the problem in your language, connects it to a meaningful outcome, and can identify where a purchase decision would live. Novelty can produce curiosity without producing demand.

Give this phase enough room to expose inconvenient facts. UserLeap used a six-month pre-launch period to refine segmentation, study a crowded market, interview customers, and examine willingness to pay. That does not make six months a universal requirement. It shows why drawing a prototype is often the short part; resolving who cares, why they care, and how they buy can take longer.

Use customer conversations to recover behavior, not opinions

You do not need a formal research department to run disciplined discovery. You do need a clear research goal, relevant participants, deliberate questions, and an explicit synthesis process. Without those controls, a sequence of friendly calls can create confidence while leaving the core assumptions untouched.

Recruit people because they have encountered the situation you are studying, not merely because they match a demographic or job title. If your hypothesis concerns a workflow, screen for recent participation in that workflow. If it concerns a buying problem, include people who understand how that purchase is approved.

Start each conversation with a real event. Ask the participant to reconstruct the last relevant occurrence from trigger to outcome. Useful prompts include:

• What happened that caused you to begin?
• What did you do first, and what happened next?
• Which people, tools, documents, or systems were involved?
• Where did the process slow down, fail, or require manual recovery?
• What did you do instead?
• What consequence did the problem create?
• Who noticed or cared about that consequence?
• What have you already tried to change?
• Why has the current approach survived?

When appropriate, ask the participant to show a sanitized artifact, screen, template, or process map. An artifact anchors the account in what actually happens. Respect confidentiality and do not request sensitive customer, employee, financial, or regulated data merely to make an interview feel concrete.

Delay the pitch until you understand the current behavior. Questions about what someone might do encourage invention. Questions about the last occurrence expose priorities, constraints, and trade-offs that already exist.

Translate feature requests back into outcomes

A feature request is a clue, not a requirement. When someone asks for a dashboard, integration, export, approval step, or AI assistant, move backward through the request:

• Which situation caused you to want this?
• What outcome is blocked without it?
• How do you handle that situation now?
• What is the consequence of the current approach?
• Why does changing it matter now?

If several participants request different features but describe the same blocked outcome, the outcome may be the stable signal. If one participant proposes many features without a recent example or consequence, you have design input, not evidence of demand.

Separate evidence from interpretation

Record what happened before deciding what it means. A compact evidence log should capture the segment, trigger, workflow, workaround, consequence, desired outcome, buying roles, direct observations, contradictions, and next uncertainty. Keep verbatim customer language separate from your interpretation so the team can challenge the conclusion without rewriting the underlying evidence.

What you hear or observe	What it can support	What it does not establish
The idea sounds interesting	The concept may be understandable or relevant	Urgency, purchase intent, or adoption
A recent event is reconstructed in detail	The problem exists in the participant’s real workflow	That the problem is common or commercially important
A workaround, artifact, or internal process is shown	The customer already invests effort in handling the problem	That your proposed solution will replace it
A prototype task is completed and the outcome is valued	The proposed interaction and result may be useful	Production use, retention, or willingness to pay
An agreed buying step is completed	The offer has enough value to justify organizational effort	Product-market fit before real use
The product is used repeatedly after launch	The product may be serving a recurring job	That the fit extends beyond the observed segment

Treat this as an evidence ladder, not a scoring formula. One enthusiastic participant should not outweigh repeated contrary behavior. At the same time, repetition alone is not enough if every participant comes from a segment you cannot reach, a use case you cannot serve, or a buyer without authority.

Test the solution, price, and buying motion without production code

A prototype is useful only when its fidelity matches the question. A polished mockup can conceal a weak value proposition because participants spend the session discussing colors, navigation, and controls. Start with the least elaborate artifact that can expose the uncertainty.

1. Test the value claim. Present a short description of the situation, outcome, and intended customer. Ask the participant to explain what it means, who it is for, and when it would matter. Confusion here is a positioning or problem-framing issue, not a missing-feature problem.
2. Test the workflow. Give the participant a realistic task in a lightweight prototype. Watch what they try to do before explaining the interface. This tests comprehension, sequence, required inputs, and whether the result fits the surrounding workflow.
3. Test the outcome manually. Where feasible, provide the intended result through a concierge or human-assisted process. Disclose what is manual. For an AI product, handcrafted output can test whether the outcome is valuable, but it cannot prove model feasibility, production quality, reliability, latency, or economics.
4. Test the offer. Put a defined scope, intended outcome, responsibilities, limits, price, and next decision in front of the actual buyer. Ask for movement in the real buying process, not a hypothetical rating.

Keep prototype cycles focused on a named question and feed the findings into the next product decision. Lightweight prototypes, clear research questions, and time-boxed iteration prevent discovery from becoming an open-ended design exercise.

Before a test, write down the belief being tested, the behavior you expect to observe, what would weaken the belief, and the decision that follows. If every possible result leads to the same roadmap, the exercise is not a test.

Make willingness to pay a buying-process question

Asking what someone would pay produces a number without its operating context. You need to know what budget or existing cost the offer competes with, who owns the decision, which approvals are required, what implementation work the customer expects, and which unresolved concern would prevent movement.

What would make this an absolute no-brainer for you in the next 30 days?

Ryan Glasgow

The value of that question is its constraint. It forces the participant to connect an outcome to a deadline and expose the remaining trade-offs. The answer is not proof by itself. Convert it into a next action: another stakeholder joins, a technical requirement is checked, a procurement step begins, a pilot scope is reviewed, or the buyer declines.

Founder-led selling is especially valuable here because discovery and qualification remain connected. Tightly scoped conversations, problem-centered demonstrations, rigorous qualification, and objection tracking turn each sales interaction into a test of the market hypothesis. An objection should update the product, segment, offer, or qualification criteria. It should not automatically become a feature.

Read commitment in levels:

• Praise: The participant says the idea is good. This costs nothing and carries little demand signal.
• Participation: The participant gives time, completes a task, or returns for another session. This shows interest in the problem or process.
• Access: The participant shares a workflow, provides permissible inputs, or helps define a pilot. This shows willingness to cooperate.
• Organizational movement: The champion brings in a buyer, approver, security reviewer, or operational owner. This shows that the opportunity can survive beyond one person’s enthusiasm.
• Economic movement: The buyer evaluates a priced offer or advances a real purchasing step. This is stronger evidence of demand, but it still does not demonstrate retention.

Not every product uses the same buying motion, and consumer products may not have visible approval steps. The principle still holds: seek behavior that costs the participant something meaningful, such as time, attention, data setup, workflow change, or money, while being honest about what that behavior proves.

Turn the evidence into a build, iterate, or stop decision

Validation becomes useful when it changes resource allocation. At the decision gate, choose one of three states:

1. Build. A specific segment repeatedly exposes the same consequential job; the current workaround is understood; the proposed outcome is valued; the buying roles and route to market are plausible; and customers take credible next steps. Most importantly, the largest remaining uncertainty now requires a functioning product in real use.
2. Iterate the validation. A real problem is visible, but the segment, trigger, language, workflow, buyer, differentiation, or offer remains unstable. Run the cheaper test that isolates that uncertainty before adding engineering cost.
3. Stop or resegment. Participants cannot produce recent examples, the status quo is acceptable, the consequence is negligible, no one owns the outcome, or interest repeatedly disappears when a concrete action is requested. Preserve the learning, but do not turn sunk discovery effort into a reason to build.

A build decision should not require certainty. It should require that code is now the most efficient way to learn something material. If another interview, workflow walkthrough, positioning test, or offer test can still answer the critical question, building is premature.

Build the smallest coherent loop

The first version is not the product with the fewest screens. It is the smallest solution that takes one well-defined customer from a recognizable trigger to the promised outcome. A thin experience that stops before the result cannot test the value thesis.

Reduce scope from the edges:

• Serve one segment and one primary job before accommodating adjacent personas.
• Support the main path before unusual exceptions.
• Limit integrations to those required to complete the outcome.
• Use transparent manual operations behind the product where automation is not the hypothesis.
• Defer configuration and customization that do not affect adoption or the promised result.
• Keep the instrumentation needed to observe activation and repeat behavior.

Do not remove the mechanism that would prove or disprove the product. If your thesis depends on collaboration, a single-user demonstration is insufficient. If it depends on repeated workflow use, a one-time output is insufficient. If it depends on trusted AI assistance, a carefully curated demo cannot substitute for evaluation on representative inputs.

A temporary product can still be rational when it has an explicit learning contract. One path toward PMF used a deliberate stepping-stone product that was not expected to be the final answer. Before making such a bet, name the uncertainty it will resolve, the behavior you will observe, the decision the result will trigger, and the investment boundary. Otherwise, temporary products have a habit of becoming permanent obligations.

Keep the organization lighter than the uncertainty

Large teams create roadmap commitments, coordination work, and pressure to keep everyone busy. Those forces are poorly matched to a stage in which the segment or product may change. Premature hiring can reduce learning velocity, while bounded contractor support can preserve flexibility before PMF.

Use a small accountable group for discovery and the first coherent build. Contractors can supply specialized execution, but the product leader or founder should retain direct ownership of customer conversations, evidence synthesis, and the build decision. Outsourcing the learning loop separates the people making the bet from the evidence that should shape it.

Write the evidence memo before roadmap approval

Bring a one-page validation memo to the decision. It should contain:

• The target segment and explicit disqualifiers.
• The trigger, job, workaround, consequence, and desired outcome.
• The user, champion, buyer, approver, and likely blockers.
• The strongest behavioral evidence and the strongest counterevidence.
• What each prototype tested and what changed afterward.
• The offer presented and the concrete commitments received or refused.
• The largest unresolved risk and why it now requires code, if it does.
• The narrow product loop you intend to build and what remains manual.
• The post-launch behavior that would support or weaken the PMF thesis.

Pre-build validation ends with permission to run a stronger test. Once the product is live, measure whether the customer reaches the promised value and returns at the natural cadence of the job. Do not confuse account creation, a successful demo, or one completed setup step with activation unless that event actually represents first value.

If usage is weak, separate the possible failures. The value proposition, onboarding, activation path, and retention loop require different diagnoses. Customers may not want the outcome, may want it but fail to reach it, may reach it once without developing a repeatable trigger, or may encounter a product failure after initial value. Treating every case as an onboarding problem only delays the harder conclusion.

At your next roadmap review, circle the riskiest claim in the evidence memo and design the cheapest test that could change your mind. If that test still does not require code, keep learning. If it does, build the complete narrow loop and name the customer behavior that will determine what happens next.

References

• Shivam.Consulting Blog – Confidently Validate Product-Market Fit Before You Build: Inside UserLeap’s Playbook
• Shivam.Consulting Blog – No UX Research Team? Proven Playbook to Validate Problems, Prototype Smart, and Nail Pricing
• Shivam.Consulting Blog – From Painful Pivots to Product/Market Fit: 0-to-1 Lessons I Drew from Rupa Health’s CEO