Dual-Track Agile Process: Discovery

Key Takeaways

‍

• Discovery is evidence-based decision-making about which problems matter, not brainstorming sessions or stakeholder opinion contests.
• Six structured activities (business goals, insights gathering, scoping, estimation, roadmap, refinement) turn assumptions into validated direction before you spend engineering resources.
• The Foundation Phase is a dedicated period of pure discovery at the start of a project or major initiative, covering business understanding, user research, technical setup, and scope definition before delivery begins.
• Discovery isn't a one-time phase. It runs continuously every sprint, validating the next sprint's work while engineering delivers the current one.

‍

What Discovery Actually Means

‍

Discovery is the systematic process of identifying what to build for users and the business. It's not a whiteboard exercise where everyone shares opinions and the loudest voice wins. It's evidence-based decision-making about which problems actually matter and which solutions will work.

‍

The goal of discovery is to enter every sprint knowing what you're building, why it matters to users, and what business outcome it will deliver. No guesses, no assumptions, just validated direction resulting in real business value.

‍

The Six Discovery Activities

‍

Discovery at OAK'S LAB follows a structured sequence:

‍

Business Goals: Defining measurable outcomes you want to achieve. Revenue targets, acquisition numbers, retention improvements. These goals drive everything that follows and map directly to your product goals. If you can't articulate what success looks like in numbers, you're not ready to start building.

‍

Insights Gathering: Collecting evidence about user problems. User interviews, surveys, product analytics, competitive analysis, and data analysis of your current or potential customer base. These insights answer the questions your team needs answered before anyone commits resources: What problems do users actually have? Which issues matter most? What do we need to build to fulfill our business goals?

‍

Scoping: Defining what you plan to build, validated with users. Every team approaches scoping differently, but the end result is the same: a clear understanding of the solution, whether that takes the form of business requirements, specifications, wireframes, or high-fidelity designs tested with potential users. A good scope also covers the simplest way to build it, achieving the maximum outcome by killing the nice-to-haves before they eat your timeline.

‍

Estimation and Prioritization: Scoring and then prioritizing features by business impact and engineering effort. You calculate which solutions deliver the most value for the least cost. Every feature earns its place on the roadmap, rather than being there because someone important asked for it.

‍

Product Roadmap: Placing validated features into a committed timeline. The roadmap shows stakeholders what's coming and when, backed by evidence rather than optimism.

‍

Refinement: Breaking down business requirements into technical specifications that engineers can execute. User stories become development tasks. Designs become implementation details. The handoff to engineering is clean because discovery already answered the hard questions.

‍

How Discovery Works in Two-Week Sprints

‍

At OAK'S LAB, we run two-week sprints where discovery and delivery occur simultaneously. While engineers deliver the validated work from the last sprint, the product team identifies the next sprint's work.

‍

The first week focuses on exploring problems and prototyping solutions. Product Leads interview users and analyze data. Design Leads create wireframes and test prototypes. Tech Leads assess feasibility and flag architectural considerations. The second week focuses on refining what you've discovered into specifications that Software Engineers can estimate and build.

‍

This rhythm means engineering never waits for discovery, and discovery never rushes to keep up with delivery. Both tracks flow continuously. The Product Lead owns the discovery track, with clear deadlines for validation tasks and a dedicated discovery backlog (typically a Kanban board) so work doesn't slip through the cracks. Stakeholders are involved in this process too, sometimes they're the best people to verify a potential solution with a customer they're already talking to.

‍

The Foundation Phase

‍

When greenfield projects start, there's too much unknown to start delivering immediately. That's why every OAK'S LAB project begins with a Foundation Phase.

‍

The Foundation Phase is a dedicated period of pure discovery, typically a few weeks at minimum and up to two months for complex products. No engineering delivery. Just systematic validation through discovery activities, informing what to build. By the end, you have:

‍

• Validated business goals and success metrics
• Evidence-based understanding of user problems through research, competitive analysis, and stakeholder interviews
• Prioritized roadmap of features to build
• Initial designs and technical architecture
• Refined specifications ready for engineering

‍

Only after the Foundation Phase does delivery work begin. This upfront investment prevents months of building the wrong thing, focuses development effort on what's been validated, and delivers tangible business outcomes rather than expensive guesses.

‍

We saw this play out clearly with a consumer fintech client. Their founders came to us with a sprawling business proposal full of passionate ideas, but the concept was scattered across too many directions and lacked a clear product focus. Weeks of structured discovery, including competitor mapping, user interviews, and quantitative research, transformed that scattered business proposal into a vision of a focused mobile app with a clear value proposition that was competitive on the market. The result: a market-ready MVP delivered in three months, complete with technical architecture positioned for future robust features in the roadmap. Without discovery, that proposal would have become a product that tried to do everything and accomplished nothing.

‍

Why Teams Skip Discovery (And What Happens)

‍

Teams skip discovery because they think they already know what to build. The founder has a vision. Stakeholders have feature requests. Competitors have features you can copy. So why waste time validating what feels obvious?

‍

Here's what happens: you build in a black box for months based on those assumptions. Launch day arrives. Users don't engage. Business goals go unfulfilled. Your engineering investment goes to waste. You've built something that solves a problem nobody actually has, or solves it in a way that doesn't fit real-world workflows.

‍

Discovery prevents this scenario. The effort put into validating before building is a fraction of the time spent recovering after a failure. It's also significantly cheaper. And it protects team morale, because nothing burns out an engineering team faster than learning that their recent work is getting scrapped.

‍

Common Discovery Mistakes

‍

Even teams that attempt discovery often get it wrong:

‍

Asking users what they want instead of what problems they face. Users are terrible at designing solutions but excellent at describing their problems. "I want a dashboard" tells you nothing useful. "I spend two hours every Monday pulling numbers from three different tools" tells you everything.

‍

Confusing feedback volume with priority. Multiple loud customers requesting a feature doesn't make it more critical than the silent problem affecting the majority of your users. The squeaky wheel gets the grease, but the quiet wheel might be the one about to fall off.

‍

Stopping discovery after the Foundation Phase. Discovery should never end. Every sprint should validate the work for the next sprint, because you'll keep gathering new information after each release that should inform what comes next.

‍

Designing solutions before validating problems. You can't create a good solution to a problem you don't deeply understand, or a problem you can't prove exists. The impulse to jump straight to wireframes is strong. Resist it until you've validated the problem.

‍

How Discovery Changes Team Dynamics

‍

When teams adopt continuous discovery, product conversations change. Stakeholders stop arguing over opinions and start discussing evidence. "I think we should build X" becomes "Users report this problem, here's the supporting data, here are some potential solutions, and here's why solution A tests better."

‍

Engineering no longer has to interpret ambiguous requirements because product specifications arrive refined and validated. Designers stop iterating in circles because usability testing reveals which approach works before development starts. Nobody wastes energy debating what to build because the evidence already points the way.

‍

The entire team aligns on a validated direction, resulting in better cohesion, a smoother development process, and business results that actually match the effort put in. This connects directly to the Outcomes Over Outputs principle: measuring success by business impact rather than features shipped.

‍

What This Means in Practice

‍

Before adding discovery to your development process:

‍

1. Review how your team currently decides what to build

‍

Look at the features on your recent roadmap. Try to trace the origin: Did it come from user research, data analysis, or prototype testing? Or did it come from a stakeholder request, a competitor feature, or someone's intuition?

‍

Validate by checking adoption rates for those features. If the evidence-backed features consistently outperform the assumption-backed ones, you've made the case for discovery. If you don't have any evidence-backed features to compare, that's also useful data.

‍

Red flag Most roadmap items can be traced back to a single stakeholder request or competitive reaction rather than a validated user need. That's a sign your team is building reactively instead of strategically.

‍

2. Run one structured discovery activity before your next feature

‍

Before your next planned feature enters development, run one discovery activity: a handful of user interviews, a prototype test, or a data analysis pass on related user behavior. See if the findings change your team's understanding of the problem or the proposed solution.

‍

Validate by comparing what you planned to build before discovery with what the evidence suggests you should build. If there's a meaningful gap, discovery just prevented an expensive mistake. If the evidence confirms your plan, you now have confidence to build without second-guessing.

‍

Red flag Your team pushes back on doing even one round of user interviews before building because "we already know what users want." That confidence is exactly the assumption that discovery is designed to test.

‍

3. Measure the cost of skipping discovery on past features

‍

Look at features that underperformed after launch (low adoption, user complaints, or features that required significant rework). Estimate what it costs: engineering hours to build, hours to rework, support tickets generated, and opportunity cost of what you could have built instead. Compare that to the cost of a couple of weeks of discovery.

‍

Validate by reviewing the costs of skipping validation internally and use it to influence how you approach the next sprint.

‍

Red flag Your team doesn't track post-launch adoption or business impact of individual features. Without that data, you can't learn from past misses, and you're likely repeating the same discovery-skipping mistakes on the current roadmap.

‍

Frequently Asked Questions

‍

How does OAK'S LAB's discovery process integrate with our existing product planning cycle?

‍

Our discovery track is designed to plug into your current rhythm, not replace it. If your team already runs quarterly planning or has an established roadmap process, OAK'S LAB's Product Lead works within that cadence. The Foundation Phase covers the initial alignment, then ongoing discovery runs sprint-by-sprint alongside your existing planning cadence. We share a discovery backlog with your product leadership, so there's full visibility into what's being validated and why. The goal is for your CTO or CPO to see discovery output flowing into the same planning artifacts they already use, not a parallel process that creates additional overhead.

‍

How does discovery scale when we're running multiple workstreams or product lines?

‍

Each workstream needs its own discovery thread, but the structure stays the same. The Product Lead on each workstream owns their discovery backlog and runs validation against their specific user segment and business goals. What changes at scale is coordination: ensuring discovery across workstreams doesn't duplicate effort or produce conflicting roadmap priorities. At OAK'S LAB, we handle this through shared steering committees and cross-workstream visibility into what each team is learning. The meetings and ceremonies layer of our process is specifically designed for this kind of multi-team alignment.

‍

What specific artifacts come out of discovery that our engineering team can actually build from?

‍

By the time a feature moves from discovery into a delivery sprint, your engineering team receives validated product requirements, tested UI/UX designs in Figma, clearly defined acceptance criteria, and an estimation that's been refined against the actual scope. The Tech Lead is involved in discovery to ensure technical feasibility and architectural considerations are baked in before anything reaches sprint planning. Engineers shouldn't be discovering open questions mid-sprint. If they are, that's a sign discovery wasn't thorough enough on that feature.

‍

How do you prevent discovery from becoming an open-ended research phase that delays delivery?

‍

By tying every discovery activity to a specific sprint deadline and a clear business question. Discovery at OAK'S LAB isn't "let's keep researching until we feel confident." Each discovery task has an owner, a deadline, and a defined output. The Product Lead is accountable for keeping discovery focused and on pace. If a validation question can't be answered within the sprint cycle, it gets scoped down or moved to the next cycle rather than holding up the delivery track. The two-track structure actually prevents this problem: because engineering is always building validated work from the last cycle, there's never a period where the whole team is waiting on discovery to finish.

‍

How does discovery adapt when we're evolving an existing product versus launching something new?

‍

The Foundation Phase is most intensive for new products or major new initiatives where uncertainty is highest. For existing products, discovery shifts toward incremental validation: testing new feature concepts against your current user base, analyzing usage data to identify opportunities, and validating whether planned roadmap items will actually move the metrics you care about. The six discovery activities stay the same, but the depth and duration change. Your team already has user data, product analytics, and market context, so discovery builds on that existing knowledge rather than starting from scratch. The Product Lead adjusts the discovery intensity based on how much uncertainty surrounds each initiative.