Dual-Track Agile Process: Validation

Key Takeaways

‍

• Validation isn't asking users "would you use this?" and treating "yes" as proof. Users can't always predict their own future behavior. Real validation tests whether a solution actually solves the problem in practice.
• Three types of validation serve different purposes: problem validation (does this matter?), solution validation (does this work?), and outcome validation (did it deliver results?). Skipping any one of the three creates blind spots.
• The User Impact Score (combining problem severity, frequency, segment size, and workaround quality) turns validation findings into prioritization decisions, replacing stakeholder opinion battles with evidence.
• Validation runs continuously through every stage of product development, not just once during discovery. Post-launch outcome validation feeds directly back into the next discovery cycle.

‍

What Validation Actually Means

‍

Validation isn't asking users "would you use this feature?" and treating "yes" as proof that the team should build it. Users typically aren't the best judges at predicting their own future behavior. If you'd asked customers what they wanted for transportation before the invention of cars, they would have asked for a faster horse. The gap isn't in what users want but in their ability to articulate solutions they've never experienced.

‍

Real validation tests whether a proposed solution actually solves the user's problem in practice. It means prototyping solutions, putting them in front of real users, and observing what happens. Do they understand it? Can they use it successfully? Does it solve their problem better than whatever workaround they're currently cobbling together?

‍

The Three Types of Validation

‍

Problem validation: Confirming that the problem you want to solve actually matters to users. Problem validation activities include user interviews, surveys, and analysis of behavioral data. You're answering: Do users actually face this problem? How painful is it? And is it painful enough that they'd change their current behavior to use a better solution?

‍

Solution validation: Testing whether your proposed solution effectively solves the problem you validated. Solution validation happens through prototype testing and usability studies. You're answering: Does this solution work for users? Can they figure out how to use it without a tutorial? Does it solve the problem better than what they're doing today?

‍

Outcome validation: Measuring whether the shipped feature created the intended business impact. Outcome validation happens through analytics and post-launch user feedback. You're answering: Did adoption meet expectations? Did key metrics improve? Or did you build something that "works" technically but doesn't move the numbers that matter?

‍

The Validation Framework: Problem to Outcome

‍

Validation follows three stages, each with specific activities, methods, and outputs:

‍

Stage 1: Problem validation

‍

Confirm the problem matters before designing solutions:

‍

• User interviews: Discuss workflow pain points with users. Don't pitch solutions. Listen to how they describe the problem in their own words, because the language they use often reveals nuances that internal assumptions miss entirely.
• Behavioral analytics: Identify where users struggle, abandon flows, or create workarounds. What people do tells you more than what they say.
• Support ticket analysis: Surface recurring confusion patterns. If your support team fields the same question twenty times a month, that's validation data sitting in your help desk.
• Surveys: Quantify how widespread the problem is across your user base.

‍

Output: Validated problem statement like "X% of users struggle with Y, causing Z negative outcome."

‍

Stage 2: Solution validation

‍

Test whether your proposed solution actually works:

‍

• Low-fidelity wireframes: Test users' understanding of the concept before investing in polished designs. A rough wireframe that confuses people saves you weeks of design and engineering time.
• High-fidelity prototypes: Reveal usability issues or gaps in complete workflows. This is where you find the edge cases that looked fine on paper but break in practice.
• Technical spikes: Validate tech feasibility before committing engineering resources. No point in validating a solution with users if it turns out to be technically impossible or prohibitively expensive to build.
• A/B testing: For significant features, test multiple approaches with different user segments and let the data pick the winner.

‍

Output: Validated design showing "Users can complete workflow X with solution Y."

‍

Stage 3: Outcome validation

‍

Measure whether the delivered feature achieved its intended result:

‍

• Adoption metrics: Are users finding and using the feature? If they can't find it, your launch strategy failed. If they find it and don't use it, your solution validation missed something.
• Usage patterns: Do they come back after the first use? One-time usage often means the feature is interesting but not valuable enough to change habits.
• Business metrics: Did it move the numbers that matter? Revenue, retention, activation, whatever success metrics you defined before launch.
• User feedback: What are users communicating in support tickets and interviews? Sometimes the quantitative data looks fine, but qualitative feedback reveals friction you'd miss otherwise.

‍

Output: Evidence of whether the feature achieved its business goals.

‍

This three-stage approach connects directly to the Outcomes Over Outputs principle. You're not just validating that something can be built. You're validating that it should be built and that it delivered results after it was.

‍

Common Validation Mistakes

‍

Validating with the wrong users. You're building an onboarding flow for HR administrators, but you test it with individual employees because they were easier to recruit. The feedback is positive, but HR admins have completely different needs, workflows, and permissions. Your validation sample needs to match your target user segment for the specific feature or flow you're testing, or you'll optimize for the wrong problems. A handful of interviews with the right users beats dozens of surveys sent to the wrong ones.

‍

Asking leading questions. "Don't you think this dashboard would help you?" isn't validation. It's confirmation bias wearing a research hat. Ask open-ended questions about their workflow and observe actual behavior instead. "Walk me through how you handled this task last week" reveals far more than "Would you use a tool that does X?"

‍

Ignoring contradictory evidence. You test a new check-out flow with users. One completes it smoothly and says it's intuitive. Seven struggle to find the confirmation step or get confused by the payment options. If the team focuses on the positive response because that user was more articulate or more senior, you'll ship a check-out flow that most users can't complete. Validation should test specific features and flows, not ask for general feedback on a full prototype, because that specificity is what makes contradictory signals actionable rather than ambiguous.

‍

Validating too late. Validation that occurs after engineering starts building leads to expensive pivots because code changes cost more than design changes. Validate early when pivoting is cheap and fast. A prototype pivot costs you days. A post-build pivot costs you months.

‍

Treating validation as optional. When timelines get tight, teams skip validation to "save time" and ship faster. This backfires when you launch features that users don't adopt, and you spend months rebuilding what validation would have caught in days. The teams that "don't have time for validation" always seem to have time for rework.

‍

How Validation Feeds Prioritization

‍

Validation drives prioritization through the User Impact Score, which combines:

‍

• Problem severity: How painful is this problem for your users?
• Problem frequency: How often do users encounter it?
• User segment size: What percentage of your user base faces this?
• Workaround quality: Are users' current workarounds adequate or terrible?

‍

High scores across all dimensions mean you prioritize. Low scores mean you icebox it. The math isn't complicated, and it eliminates the debates over which feature comes next that eat up sprint planning time and leave nobody satisfied.

‍

This framework is how Product Leads in THE OAK'S LAB WAY make prioritization decisions: backed by evidence from validation, not by whoever argues loudest in the meeting.

‍

How Validation Changes Stakeholder Conversations

‍

Without validation: "I think we should build X." "I disagree, Y is more important." Repeat until someone gives up or the deadline forces a decision.

‍

With validation: "We interviewed users in our target segment. The majority struggle with completing the onboarding flow independently. We tested a simplified prototype, and most completed it without help. Here's the impact score and adoption projection."

‍

Evidence ends opinion battles. It doesn't eliminate disagreement entirely, but it moves the conversation from "I think" to "the data shows," which is a dramatically more productive starting point.

‍

We saw this shift clearly during our work with a healthcare startup doing over $1B in annual revenue whose manual customer onboarding process took months. Problem validation confirmed the bottleneck: the process wasn't just slow, it was fundamentally workflow-driven rather than technology-driven. The problems the team validated were tied directly to business outcomes: every month of manual onboarding was a month of delayed revenue and constrained growth capacity. Solution validation tested a template-based approach with actual clinical teams before engineering wrote any code, revealing that the real friction points were different from what the internal team had assumed. The team iterated on the prototype until users could complete the process without hand-holding. The result was a platform that reduced onboarding from months to minutes. Without that structured validation, engineering could have automated the wrong workflow and spent months building a solution nobody could use.

‍

The Validation Cycle

‍

Validation runs continuously throughout the product lifecycle:

‍

• Pre-discovery: Validate there's a problem area that deserves attention before committing discovery resources to it.
• During discovery: Continuously test prototyped solutions with users as discovery refines the approach.
• Pre-development: Ensure the proposed solution is fully validated before it enters the delivery sprint. Engineers should never start building something that hasn't been tested with real users.
• Post-launch: Measure outcomes and gather feedback, then feed those findings back into the next discovery cycle.

‍

This continuous validation prevents building the wrong thing at any stage. It's not a one-time activity you do at the start of a project and check off the list. It's a discipline that runs every sprint as part of Dual-Track Agile.

‍

Why Validation Isn't Optional

‍

Validation takes time, and there's no way around that. But building the wrong feature wastes weeks or months of engineering effort, and rebuilding after launch costs even more. The math is straightforward: spending a few days testing assumptions upfront is far cheaper than discovering a feature missed the mark after your team has already shipped it.

‍

This is why validation isn't a nice-to-have in Dual-Track Agile. It's the mechanism that keeps discovery and delivery aligned, ensuring your delivery track isn't burning cycles on solutions that don't actually solve user problems.

‍

What This Means in Practice

‍

Before improving your team's validation practices:

‍

1. Review how many of your current features were validated before development

‍

Look at the features your team shipped in recent quarters. Can you point to evidence that the problem was validated with users, the solution was tested with prototypes, and success metrics were defined before launch? Were the problems being solved tied to measurable business outcomes like revenue, retention, or activation? Or did most features go from "someone requested this" to "engineering is building it" without a validation step or a clear connection to business impact?

‍

Validate by comparing adoption rates for validated versus unvalidated features. If you don't have any validated features to compare against, that tells you everything you need to know about your current process.

‍

Red flag Your team can't distinguish between features that were validated and those built on assumptions because nobody tracks whether validation occurred.

‍

2. Check whether your validation matches your target users

‍

Review recent rounds of user research or prototype testing your team conducted. Were the participants representative of your actual target users for the specific feature being tested? Or did the team test with whoever was available, regardless of whether they matched your target segment?

‍

Validate by checking whether your validation participant selection is driven by fit (matching the target segment for that feature) or by convenience (whoever responded fastest or was already in the pipeline). If it's consistently the latter, your validation results may be telling you what available users think rather than what your actual users need.

‍

Red flag Your validation consistently produces positive results, but post-launch adoption is low. That disconnect often means you're validating with enthusiastic early adopters or internal stakeholders rather than with the mainstream users who make up the bulk of your market.

‍

3. Check where your validation findings live and whether they're actually used

‍

Look at where your team stores validation findings. Is there a structured repository that the product team references when prioritizing the pipeline? Are the findings high quality, with clear problem statements, user evidence, and business impact? And most importantly, is the team actively using these findings to validate the features they have in the pipeline, or are they sitting in a document nobody opens?

‍

Validate by tracing recent features from pipeline to delivery. Can you follow the thread from a validation finding to a prioritization decision to a sprint commitment? If that thread doesn't exist, validation findings are being collected but not connected to what actually gets built.

‍

Red flag Your team has validation artifacts (interview notes, test results, research summaries) but nobody references them during sprint planning or prioritization. That means validation is happening as an activity but not functioning as a decision-making input. The findings exist, but they're not changing what the team builds.

‍

Frequently Asked Questions

‍

How many users do we need for validation to be meaningful?

‍

For qualitative validation (user interviews, prototype testing), five to eight users from your target segment typically reveal the major usability issues and problem patterns. You'll see diminishing returns quickly because the same themes start repeating. For quantitative validation (surveys, A/B tests), you need statistically significant sample sizes that depend on your user base and the magnitude of the effect you're measuring. Start with qualitative. It's faster, cheaper, and catches the big problems. Add quantitative when you need to scale decisions across a larger base.

‍

What do we do when validation contradicts what stakeholders want?

‍

Present the evidence transparently. Show stakeholders real users struggling with their proposed solution, not just a summary slide. Most come around when they see the data. For when intuition alone feels strong enough, ship a minimal version to a small user segment and measure real adoption. If the stakeholder's instinct is right, the data will show it. If validation was right, you've limited the blast radius. Either way, you've replaced opinion with evidence.

‍

How do we validate when we're building something entirely new that users haven't experienced before?

‍

You can't validate the exact solution, but you can validate the problem and the approach. Test whether users actually face the pain point you're solving. Show them low-fidelity concepts and observe their reactions. Test analogous workflows to see if the interaction patterns make sense. The faster horse quote gets misused to justify skipping validation entirely. What it actually means is: validate the problem (people need to get places faster), not the specific solution (a horse). Then test whether your proposed solution actually works for users before committing full engineering resources to it.

‍

Validation takes time we don't have. How do we speed it up?

‍

Most validation can happen in days, not weeks. A handful of user interviews takes a couple of days. A prototype test takes an afternoon. A support ticket analysis can happen in hours. The perception that validation is slow often stems from teams that treat it as a formal research project, with recruitment phases and detailed reports. In Dual-Track Agile, validation is embedded in the sprint rhythm. The Product Lead and Design Lead run validation activities while engineers deliver the current sprint's work. It happens alongside delivery, not as a separate phase that blocks engineering.

‍

How does validation work with an external development partner like OAK'S LAB?

‍

Validation is built into the Dual-Track Agile process, so it happens as part of the standard workflow rather than requiring a separate initiative. Every feature that reaches engineering has been validated through problem interviews, prototype testing, or data analysis during discovery. At OAK'S LAB, we operate as an extension of the client's team, meaning our Product Leads and Design Leads can act on behalf of the client and engage directly with their users. Clients feel comfortable putting us in front of their customers because we're embedded in their organization, not operating as an outside vendor. The client participates in validation activities because they know their users best, and the OAK'S LAB team brings structured validation methods and an outside perspective that challenges internal assumptions. That combination of insider access and outsider objectivity is actually a strong position for validation, because we don't carry the same biases about "what users want" that internal teams develop over time.