The 5 Validation Questions: What Every Project Must Answer Before Code

The most expensive mistake in software is not building something that breaks. It is building the wrong thing confidently. A clean codebase, a disciplined team, a well-managed sprint cadence — none of it matters if the product solves a problem nobody has, solves the right problem in the wrong way, or solves it for an audience that was never going to pay. The wreckage doesn't look like failure. It looks like a polished product that nobody needs.

Most founders and product leaders understand this intellectually. They nod when someone says "validate before you build." And then they skip validation anyway — not out of arrogance, but because they don't have a concrete framework for what validation actually means before a line of code is written. "Have we validated?" is too vague to answer. The real question is: have we answered the five specific questions that determine whether this project should exist?

At EB Pearls, these five validation questions are applied to every project before scope locks. Not optional. Not negotiable. Across 600+ products shipped and 900+ projects delivered, we have seen what happens when any one of them is skipped — and the cost is measured in months and significant budgets, not hours and minor expenses. The Discovery Workshop™ exists precisely to force these questions into the open before a Fixed-Price Proposal is issued, because a locked scope built on unvalidated assumptions is just a precise plan to build the wrong thing.

This article lays out the five questions, what a passing answer looks like for each, and what happens when teams skip them.

Why Skipping Even One Question is Expensive

The temptation to move fast is understandable. You have a market window. You have a budget cycle. You have a competitor who launched something last month. The pressure to start building is real, and validation feels like a delay. But the data on what happens without it is unambiguous.

CB Insights analysed over 100 startup post-mortems and found that the number one reason for failure was building something the market did not need — ahead of running out of cash, team problems, and competition. The product worked. The market didn't want it. That is a validation failure, and it is the single most common way software investments fail.

The reason it happens so often is that teams confuse confidence with validation. A founder who has spent three months thinking about a problem feels certain about the solution. A product manager who has collected a backlog of feature requests feels certain about what to build next. A CTO who has solved similar technical problems before feels certain about the architecture. But certainty is not evidence. The five validation questions exist to convert certainty into evidence — or to reveal that the certainty was unfounded before the money is spent.

Each question addresses a different category of risk. Skip the first, and you build a solution to a problem that is too small or too rare to sustain a product. Skip the second, and you build for an audience that will never adopt. Skip the third, and you overbuild when a simpler path existed. Skip the fourth, and you deliver something technically sound that fails commercially. Skip the fifth, and you launch without knowing whether you succeeded. Five questions. Five categories of risk. Each one capable of sinking a project on its own.

The Five Questions and What Passing Looks Like

Every project that enters our delivery process must answer these five questions during discovery. The Riskiest Assumption Test™ — the single assumption the product depends on that has not been validated by real users — is identified and addressed before development begins, not after launch. Here is what each question asks and what a credible answer looks like.

Question One: Is this a real problem or an assumed one?

The question sounds obvious. It is not. A surprising number of products are built to solve problems that exist in the founder's mental model but not in the daily reality of the target user. The problem might be real but too infrequent to justify a product. It might be real but already solved well enough by existing behaviour. It might be real for the founder but not for the market they intend to serve.

A passing answer looks like this: You can point to direct evidence — user interviews, support tickets, usage data from an existing product, or measurable operational pain — showing that the problem occurs frequently enough and painfully enough that people will change their behaviour to solve it. "We think this is a problem" is not a passing answer. "Fourteen of twenty users we interviewed described this problem unprompted, and three are currently paying for workarounds" is a passing answer.

When it is skipped: The team builds a product that works beautifully and solves a problem nobody has urgently enough to adopt. The launch is quiet. User acquisition is a grind. Six months in, the team is debating whether the marketing is wrong when the product is wrong.

Question Two: Who exactly will use this, and will they pay or switch?

Identifying a target audience is not the same as validating that the audience will act. "Small business owners" is a demographic, not a validated user base. The question is whether a specific, reachable group of people will change their current behaviour — stop using what they use now, start using your product, and either pay for it or engage with it consistently enough to create value.

A passing answer looks like this: You can describe your initial user in specific terms — their role, their current workflow, the moment in their day when they encounter the problem — and you have evidence (not assumptions) that they are willing to switch. Evidence might be letters of intent, waitlist signups with a deposit, successful pilot usage, or documented dissatisfaction with their current solution gathered through structured validation.

When it is skipped: The product launches to an audience that was described in a slide deck but never confirmed in reality. The team discovers that the people they assumed would use the product either do not have the problem, have solved it already, or are not willing to change their workflow for the improvement being offered.

Question Three: Is this the right solution or just the familiar one?

This is the question that gets skipped most often — and it is the most expensive to skip. Once a team has confirmed that a real problem exists for a real audience, the instinct is to jump to the solution they know: build a custom platform, build a mobile app, build the thing they are good at building. But the right solution is not always a custom build. Sometimes it is a configured SaaS product. Sometimes it is an integration between existing tools. Sometimes it is an MVP that tests the core value proposition before a full platform is committed.

A passing answer looks like this: You have evaluated at least two alternative approaches — including the simplest possible version and a non-custom option — and you can articulate specifically why the chosen solution path is better for this problem, this audience, and this stage of the business. The answer should address build complexity, time to market, and what happens if the core assumption is wrong.

When it is skipped: The team builds the solution they defaulted to, not the solution the problem required. Six months and a substantial investment later, the custom product has feature parity with an off-the-shelf tool — and none of the advantages that would have justified the build.

Question Four: What does the commercial model look like, and does it work?

A product can solve a real problem for a real audience with the right solution — and still fail because the economics do not work. The cost to acquire a user exceeds the revenue that user generates. The price point that the market will bear does not cover the cost of delivery. The total addressable market is too small to sustain the infrastructure the product requires.

A passing answer looks like this: You have a documented commercial model — not a financial forecast full of optimistic assumptions, but a basic unit economics analysis that shows how the product generates more value than it consumes. Customer acquisition cost, lifetime value, gross margin per user, and the break-even point should all be grounded in evidence or conservative estimates. For products that are not directly revenue-generating, the answer should quantify the operational savings or strategic value and compare that against the cost of the build.

When it is skipped: The product launches, gains users, and then the team discovers that growth makes the problem worse, not better. Every new user costs more to acquire than they generate. Scaling is not a celebration — it is a faster path to loss.

Question Five: How will we know if this worked?

This is the question that connects validation to accountability. If the product launches and performs exactly as designed, what specific numbers will tell you it succeeded? Not "users like it." Not "revenue is growing." Specific metrics, with thresholds, evaluated at defined intervals.

A passing answer looks like this: You can name three to five metrics — covering user behaviour, business outcomes, and technical health — each with a target number and a date by which it will be evaluated. "Monthly active users reach 2,000 by day 90" is a passing answer. "We will track engagement" is not. The metrics should be instrumentable, meaning the product can be built to capture the data required to measure them.

When it is skipped: The product launches and nobody agrees on whether it worked. Marketing claims success by one measure. The board questions it by another. The conversation about the next phase stalls because there is no shared definition of what the first phase was supposed to achieve.

Running the Five Questions in Practice

The five questions are not a theoretical exercise. They are answered during discovery and documented in the Locked Scope Document™ that governs the build. Here is how the process works in practice.

Start with question one and do not move forward until it passes. The temptation is to run through all five questions in a single workshop. Resist it. If the problem is not validated, the remaining four questions are irrelevant. Spend the time here. Interview users. Review data. Challenge the assumption that the problem is real, frequent, and painful enough to justify a product.

Questions two and three run concurrently. Once the problem is confirmed, audience validation and solution evaluation can happen in parallel. User research informs both — understanding who will use the product also reveals what kind of solution they will adopt. This is where the build versus buy decision gets made with evidence rather than instinct.

Question four is a gate, not a formality. Commercial viability analysis should be rigorous enough to kill a project. If the unit economics do not work at realistic scale, the project should not proceed regardless of how compelling the problem, audience, and solution are. This is the question that protects the investment.

Question five gets locked into the scope document. Success metrics are not an appendix. They are part of the project definition. The instrumentation required to measure them is included in the development backlog. If a metric matters enough to define, it matters enough to build the infrastructure to capture it.

The entire sequence — all five questions answered, documented, and agreed — typically takes two to four weeks depending on the complexity of the product. That investment of weeks routinely prevents the waste of months.

What Happens When Question Three Gets Skipped

A founder came to us with a clear problem and a clear audience. Both validated. Customer interviews confirmed the pain. The market was well-defined. But the founder had already decided on the solution: a custom-built platform with a bespoke workflow engine, custom reporting, and a mobile companion app.

During discovery, we asked question three. We evaluated three alternative approaches, including a configured SaaS product that covered roughly 80% of the required functionality and could be deployed in weeks rather than months. The custom build would take six months minimum and require a substantial investment. The SaaS path would take six weeks and a fraction of the cost.

The founder had seen this pattern before — in a previous company, a SaaS tool had been insufficient and they had regretted not building custom from the start. That experience created a bias. The previous context was genuinely different — a larger user base, more complex workflows, regulatory requirements that the SaaS could not meet. This project had none of those constraints.

In this case, the founder heard the analysis and chose the SaaS path. But the composite we see more often goes the other way. The custom platform gets built. Six months and a significant budget later, it reaches feature parity with the SaaS it could have configured — and has none of the ecosystem advantages, marketplace integrations, or ongoing vendor-maintained updates that would have come with the simpler path. The custom build was not wrong because it failed. It was wrong because it succeeded at doing something that did not need to be built.

When the Five Questions Matter and When They Can Wait

Answer all five before code if you are committing meaningful budget to a product build — whether that is a mobile app, a custom software platform, or a major new feature set. The questions are non-negotiable when real money is at stake and the product's purpose is to deliver a business outcome.

A lighter version applies if you are running an experiment, a technical spike, or a proof of concept. In that case, questions one and five are still essential — you need to know you are testing a real problem and you need to know what a successful test looks like. Questions two through four can be deferred until the experiment confirms that a full build is warranted.

The worst time to ask these questions is three months into development. By then, sunk cost bias has set in, the team is emotionally invested, and the honest answer to "is this the right solution?" becomes politically impossible. The five questions work because they are asked when walking away is still cheap.

Where to Start

Pick the project you are about to commit budget to. Answer the five questions in writing — not in your head, not in a conversation, in a document. If any question does not have a passing answer, that is the question you need to resolve before scope locks.

When you are ready to run the five questions with a team that will not let you skip one, talk to our team. We run the validation before the proposal — because a fixed price means nothing if the product is built on an unvalidated assumption.

Frequently Asked Questions