Module 4 -- Proving the Answer: How to Validate a Product Idea Before You Build It

If you have been through Module 3, you will remember where we left Feedloop. Gate 2, a validated problem, a clear signal that synthesis was the real breakdown. Gate 2 said the problem was worth solving. This module picks up exactly there. We are going to watch Stage 2 and Stage 3 run, from the first solution concept all the way to the build decision. By the end of this session, I want you to understand what Stage 2 is actually for. what genuine validation looks like in practice, and what it takes to earn a build decision rather than just make one. Stage 1 confirmed that synthesis, not organization, was the breakdown. Eleven of 13 interviews pointed to the same place. That finding became the foundation for everything that follows. What Stage 1 handed forward is not a general direction. It is a specific, evidenced problem worth solving. Stage 2 begins from that specificity. Feed Loop cleared Gate 2. They know the problem, they do not yet know the solution, and they do not yet know if a solution is possible. That is exactly the right place to start Stage 2. Two questions across two stages. Stage 2 asks, what could we build? Stage 3 asks, does the evidence support building it? The build decision only happens after both questions have honest answers. I want to walk through Feedloop's experience of both stages because the details matter. The decisions they made along the way are the decisions your teams face, too. Feedloop's team had an immediate answer. Templates. Templates would organize the synthesis output. Templates felt familiar, safe, feasible to build. That confidence was the danger. The first plausible solution is not a bad hypothesis. It is simply the one that arrived first, with the energy of recognition behind it. Stage 2 exists because that instinct, left unchallenged, becomes the next feature shipped. That pull toward the comfortable first solution is a human pattern, and naming it is the first thing the human foundation asks you to do. So, how does Stage 2 create that space? Through the Opportunity Solution Tree. Some of you may already use the OST. That is fine. What I want you to notice is what changes when it is built on Stage 1's outputs. The outcome at the top is not something the team chose in Stage 2. It is the validated job statement from Stage 1. The opportunity branches are not brainstormed in a workshop. They are the scored needs that evidence produced. The only genuinely new thing at Stage 2 is the solutions. Feedloop generated seven solutions for their top scoring opportunity. Templates were among them. AI synthesis with evidence display was also among them and would never have been seriously considered without OST discipline. Templates were rejected. They organize synthesis output but leave the cognitive work of synthesis and verification entirely on the customer. AI synthesis with evidence display was selected because both components together fulfill the job. reduce synthesis time, and make conclusions defensible by showing the source evidence behind each pattern. Before you can select a solution, you need to know what you are betting on. That is where assumption mapping comes in. Every solution concept is a bundle of assumptions. Some of them are well-grounded, others are hopes dressed up as facts. Feedloop's most dangerous assumption was that LLM accuracy could reach 80% on their data. If that turned out to be false, the entire AI synthesis concept was dead. Everything else they might test would be irrelevant, so they mapped their assumptions by risk. Highest uncertainty, highest consequence. Test first. This is a discipline worth building into your own practice. The riskiest assumption determines the test order. Once they knew what they were betting on, they needed something to test against. That is the prototype. Here is what that mapping looks like in practice. Three assumptions, three risk profiles, one clear sequence. Assumption one, LLM accuracy will be sufficient. Critical, test first. If wrong, nothing else matters. Assumption two, they can build or source the right data. High risk, validate early. Assumption three, users will trust AI-generated insights. High risk but only meaningful once the first two assumptions hold. The sequence is the discipline. You do not pick the easiest assumption to test. You pick the most dangerous one. The Solution Experience Map is the artifact that converts Stage 1 evidence into a prototype specification. It is not a wireframe. It is a map of the intended user experience. How job stories connect into flows, where the emotional high points land, what the wow moments are, and what experience quality the prototype must deliver. Everything from Stage 1 feeds into it. The job statement sets the outcome the experience must serve. Opportunity scores identify where the current experience breaks down. Job stories define what the user must be able to accomplish. The assumption map flags what is most uncertain. Feed Loop's SEM AHA moment, when first AI synthesis runs, evidence panel, where customers verify conclusions against source quotes, collaborative review that follows. The evidence panel was designed here because the job required defensible conclusions, not just faster synthesis. That design decision is what made the stage 3 usability finding consequential, not just cosmetic. A prototype is not a first draft of the product. It is a hypothesis made testable. Feed loop started with something even more focused, a technical spike. Not the prototype, just a bounded test of the one assumption that could kill everything. Can LLM accuracy reach 80% on our data? 83% above threshold. Feasibility cleared. Only then did they build the prototype, specifically to test the assumptions a technical spike cannot reach. whether users would trust AI output when evidence is shown, and whether they could verify AI conclusions. Testing the assumptions that worry you rather than the ones that reassure you takes exactly the kind of courage the human foundation asks for at every hard judgment point. Gate 3 is the decision point that comes next. Gate 3 asks one question, is the team ready to test? Not, will it work? Readiness to test is not a prediction of success. It is a check that four things are in place. The solution direction is clear, the assumptions are mapped, the tests are designed, and the prototype is in hand. An iterate or stop at gate 3 is not a failure. It is stage 2 doing exactly what it is supposed to do before resources are committed to validation. Feedloop had all four conditions. Gate 3. Proceed. Now they are in Stage 3, and here is where the mindset shift matters most. Most teams enter Stage 3 hoping to prove they were right, and when they do, they design tests that are easy to pass, interpret ambiguous results as positive, and dismiss the signals they did not want to find. That is not validation. That is confirmation theater. The distinction matters enormously for what comes next. Feedloop saw four of five users complete the synthesis task successfully. The temptation, and I mean this genuinely, was to call it done. 80%. Good enough. Ship it. The learning mindset asked a different question. Why did one user struggle? What does that tell us about the evidence panel display? That question followed rigorously, led to a redesign. And that redesign made the feature genuinely usable at launch. The one user who struggled was not noise. That user was the most important signal in Stage 3. What does validation actually test? Four things. Desirability, usability, feasibility, viability. All four must clear threshold. Not three out of four. All four. Notice viability includes the ethical dimension. Should we build this? Not just, can we make money? Should it be built at all? That is a real question and it belongs in the framework. Feed loop. 85% desirability, 80% usability with one flagged issue, 85% feasibility confirmed by the technical spike, and 70% viability with enterprise scalability uncertain. Those numbers are not an average. They are four separate calibrated judgments. And what you do with them requires one more piece of thinking. Feedloop's evidence had two signals that needed honest handling. First, high desirability, but one of five users struggled with the evidence panel. Four of five passing the criterion did not make that fifth user's struggle invisible. The calibrated confidence move was to follow it. The team redesigned the evidence panel before launch. The usability score remained 3.5, not 4, because that is what the evidence showed. Second, Viability at 70%. Enterprise scalability was genuinely uncertain. The calibrated confidence move was to name it, not smooth it. The team entered delivery with eyes open to that risk. Calibrated confidence means the score reflects what you found, not what you hoped. That is what the confidence dashboard captures. The dashboard is not a scorecard. It is an honest account of what the evidence showed. Desirability 4 out of 5 Feasibility 4 out of 5 Usability 3.5 with one required iteration committed before launch Viability 3 out of 5 with enterprise scalability uncertainty named and documented Gate 4 asked, Given this evidence, what should be done? I want to be direct about something A stop at Gate 4 costs weeks Proceeding despite weak evidence costs months What the framework makes possible is the decision to stop before that cost is paid. That decision requires the team to honestly assess the evidence rather than advocate for the solution they have invested weeks building. The sunk cost pull toward build after weeks of work is real and predictable. One more moment where the human foundation is actively required, not just structurally present. Feed loop. Build. One required iteration. Named. committed, documented before proceeding. That question is the one worth sitting with after this session. Not in theory. In something specific, a product decision you are working on right now, an assumption your team is treating as fact without having tested it. The riskiest assumption is the one that, if wrong, changes everything. Has it been tested, or is it being believed because testing it is uncomfortable? Module 5 picks up at Gate 4 Build and walks Stage 4, what happens when the decision to build has been made, and how the discovery work becomes the foundation for delivery.

The first plausible solution is not the right solution, it is simply the one that arrived first. This module walks Stages 2 and 3: Opportunity Solution Tree, assumption mapping, prototyping, and the four-dimension validation model that earns a build decision rather than just making one.

Discovery Navigator (free): https://unvera.ai/pages/navigator
Product Discovery Handbook (coming September 2026): https://unvera.ai/pages/book
Unvera Website: https://unvera.ai

Chapters
0:00 Introduction
0:37 Recall: Module 3
1:02 Stage 2: What Could We Build?
1:39 The First Plausible Solution
2:23 Opportunity Solution Tree
3:37 Assumption Mapping
4:17 Test The Riskiest First
4:58 Solution Design
6:07 Assumption Testing
7:42 Validation vs Confirmation Theatre
8:42 Four Validation Dimensions
9:32 Evidence Synthesis
10:23 Gate 4: Build, Pivot Or Stop
11:32 Module Wrap Up