Pillar 3: Activities

Key Takeaways

‍

• Shipping velocity without validated demand produces features nobody uses and engineering time you can’t get back.
• Dual-Track Agile runs discovery and delivery in parallel, so your team validates what to build while engineering ships what has already been validated.
• Discovery doesn’t slow development down. It prevents the costly rebuilds and pivots that actually slow you down.
• Eight interconnected components keep both tracks aligned on the same business goals without creating coordination overhead.

‍

The Problem with Build-Only Teams

‍

Traditional Agile runs in a single mode: execution. Take requirements, estimate them, sprint them, ship them. This works beautifully when you already know precisely what to build.

‍

Unfortunately, companies rarely have that luxury.

‍

Your market is shifting. Competitors launch new features monthly. Customer expectations and behavior evolve faster than your roadmap can keep up with. When you start building without validating first, your engineering team works at full capacity while your business outcomes stay completely flat. Everyone is busy, but nothing of value moves.

‍

The cost compounds

‍

• Engineering quarters spent on features that don’t move your metrics
• Technical debt accumulates from solutions nobody ends up using
• Missed opportunities while your team rebuilds what should have worked the first time

‍

This is exactly the problem that our product-building principle, Outcomes Over Outputs, addresses. Activities are where that principle turns into a concrete process.

‍

How Activities Work in THE OAK’S LAB WAY

‍

Activities represent our approach to structuring work so your team validates before they build. We follow Dual-Track Agile, running two parallel tracks simultaneously.

‍

Track One: Discovery

‍

What it does: Validates the problems actually worth solving before engineering starts writing code.

‍

Your product team explores user problems, tests assumptions, and figures out what to build next. They’re answering the critical questions before you commit engineering resources: Are we solving the right problem? Will this solution actually work for users? What’s the simplest version that delivers the most value?

‍

Discovery activities:

‍

• User interviews to understand actual needs (not the needs you assumed they had)
• Prototype testing to validate solutions before writing production code
• Qualitative and quantitative analysis to identify where users struggle
• Competitive research to understand your market positioning

‍

Track Two: Delivery

‍

What it does: Builds, tests, and ships validated solutions with predictable velocity.

‍

Your engineering team works on de-risked, validated problems. They know precisely what they’re building and why it will deliver impact, because discovery already answered the hard questions. No guessing needed. No building features based on hunches or opinions.

‍

Delivery activities:

‍

• Engineering implementation within your established architecture
• Quality assurance testing against validated success criteria
• Production deployment through standardized pipelines
• Performance monitoring to track user impact post-launch

‍

Both tracks run simultaneously. While Engineers deliver the current sprint’s validated work, the Product Lead and Design Lead discover and validate the next sprint’s work. No waiting around. No bottlenecks between the two. Just a continuous flow of validated problems turning into shipped solutions.

‍

The Eight Components That Make It Work

‍

Dual-Track Agile isn’t just "do some discovery work on the side." It’s a comprehensive methodology with eight interconnected components that keep both tracks aligned on the same goals:

‍

Discovery validates problems worth solving long before any engineering work begins. We identify assumptions, test them with real users, and figure out what to build.

‍

Delivery builds, tests, and ships with predictable velocity. Your developers follow validated requirements with clearly defined success criteria, not vague feature requests.

‍

Meetings & Ceremonies keep both tracks aligned without creating meeting overhead that eats into building time. Specific rituals ensure teams coordinate efficiently without living in conference rooms.

‍

Estimations map work out realistically, so teams can commit with confidence and maintain a sustainable pace. No death marches. No "we’ll figure it out as we go."

‍

Launch Strategy & Checklist ensure every release is actually ready for users with systematic pre-launch checks. Shipping a feature that breaks on day one is worse than not shipping it at all.

‍

Validation tests assumptions continuously with real users and real data throughout both tracks, not just at the start but as an ongoing discipline.

‍

Iteration Cycles structure work into sustainable rhythms that balance speed with learning. Two-week sprints keep the team moving without burning out.

‍

Strategic Innovation & Predictable Delivery balances exploring new opportunities with executing your validated roadmap. You don’t have to choose between innovation and reliability.

‍

This entire framework sits within our broader product development methodology, where these activities connect to the principles, roles, and tools that make the whole system work together.

‍

Why This Matters

‍

Post-fundraising, pressure builds on your product development process from every direction. Your board expects rapid annual ARR growth. Your sales team needs new features to close enterprise deals. Marketing wants enhancements that drive acquisition. Your engineering team faces a backlog of competing priorities with no clear way to sort them.

‍

When you don’t have structured activities and a disciplined process, you end up optimizing for whoever lobbies the hardest or gets their request in first.

‍

With Dual-Track Agile, you optimize for the work with the most significant business impact.

‍

What changes:

‍

Discovery activities give your team the evidence they need so they aren’t debating what to build based on opinions and assumptions. Solutions are validated before development begins, eliminating rebuilds, costly mistakes, and wasted engineering resources on low-impact features. Priorities come from business needs and user behavior, with clearly defined metrics for success.

‍

The Business Impact

‍

Companies that successfully run both discovery and delivery consistently achieve more with the same (or fewer) resources:

‍

Higher success rates. Your features ship with validated demand, not assumed demand. That’s the difference between features that get adopted and features that sit unused.

‍

Predictable velocity. Engineering works on de-risked problems with clear success criteria, which means fewer surprises mid-sprint and more reliable delivery timelines that your stakeholders can actually plan around.

‍

Better resource allocation. Design and development time goes toward building features you’ve already validated with users, not features you’re hoping will work out.

‍

Faster learning cycles. Your team discovers what won’t work and what will work faster, saving significant time and money. The learning happens during discovery, when changes are cheap, not after launch, when they’re expensive.

‍

Dual-Track Agile and this structured approach aren’t just theories. It’s how we’ve helped companies from pre-seed to Series D build products that users actually adopt.

‍

What This Means in Practice

‍

Here’s how our teams structure Activities from the start of every engagement.

‍

1. We audit how much of the current work is validated before engineering starts

‍

In the first couple of weeks, we look at what shipped recently. How many of those features went through some form of user validation (interviews, prototype testing, data analysis) before development began? And how many went straight from a stakeholder request or roadmap item to engineering?

‍

• Validate by checking adoption rates for validated versus unvalidated features. The difference is usually dramatic and makes the case for discovery on its own.
• Red flag: Most features go from "someone asked for this" to "engineering is building it" with no validation step in between. That’s the build-only trap.

‍

2. We identify where discovery can run in parallel with current delivery

‍

We look at the current sprint structure. While engineering builds this sprint’s features, is anyone validating what goes into the next sprint? If not, the planning process is reactive rather than proactive, and we start closing that gap.

‍

• Validate by asking the Product Lead: "Do we know, right now, what we’re building two sprints from now and why?" If the answer is vague, there isn’t a discovery track. There’s a backlog.
• Red flag: Sprint planning regularly involves debating what to build rather than refining how to build already-validated work. That’s a sign the team is doing discovery and delivery in the same sprint, which defeats the purpose.

‍

3. We introduce discovery activities without disrupting delivery

‍

We don’t implement full Dual-Track Agile overnight. We start by adding one discovery activity (user interviews, prototype testing, or data analysis) to the current process and run it alongside the normal delivery sprint.

‍

• Validate by checking whether the discovery insights change what the team builds in the following sprint. If they do, we’ve proven the value. If they don’t, either the insights aren’t reaching the right people or the prioritization process isn’t incorporating them.
• Red flag: The team treats discovery as optional or "nice to have," and it gets dropped whenever delivery pressure increases. Discovery only works if it’s protected the same way we protect engineering sprint time.

‍

Common Questions About Activities and Dual-Track Agile

‍

Q: How does OAK’S LAB introduce these activities to a team that already has an established process?

‍

A: We don’t rip out what’s working. In the first few weeks, we observe how the team currently operates, where decisions stall, and where work gets redone. Then we layer in the activities that address the biggest gaps. If the team already has solid delivery ceremonies but zero discovery, we start there. If standups exist but sprint planning is chaotic, we focus on that. The eight components are a complete system, but we introduce them incrementally based on where the team feels the most friction. Nobody wakes up one Monday to a completely different process.

‍

Q: What happens when discovery and delivery get out of sync?

‍

A: It happens, especially early on. The most common version is discovery getting ahead of delivery by several sprints, or falling behind because the Product Lead gets pulled into delivery fires. We catch this during sprint planning and retros. If the discovery backlog is empty and engineering is about to start guessing what to build next, that’s a scheduling problem we fix immediately. The whole point of running both tracks in parallel is that they feed each other, so when one stalls, the other starts burning through validated work or building without validation. Either way, it shows up fast.

‍

Q: How do the eight components avoid turning into bureaucracy? That’s a lot of process.

‍

A: Fair concern. The distinction is between structure and overhead. Each component exists to answer a specific question the team would otherwise waste time figuring out ad hoc: What are we building next and why? How do we know it’s ready to ship? How do we estimate without guessing? The teams that resist structure the most are usually the ones spending the most time in Slack threads debating what "done" means or re-scoping mid-sprint. We’ve found that defining these activities once, clearly, frees up more time than it costs. If a ceremony or process isn’t earning its keep, we cut it.

‍

Q: How does OAK’S LAB handle it when stakeholders push to skip validation and ship now?

‍

A: We show them the cost of skipping it. Pull up the features from a recent quarter that shipped without discovery and check their adoption rates. In most cases, a significant portion will have low adoption, which represents engineering time and money spent on outcomes nobody wanted. We frame discovery as the activity that prevents wasting budget, not the activity that delays features. Most stakeholders come around quickly once they see the data. The Outcomes Over Outputs principle is useful here too, because it gives the team a shared language for pushing back on "just build it" requests.

‍

Q: Does this replace our existing Agile process, or sit on top of it?

‍

A: It sits on top. Your sprint planning, standups, retrospectives, and delivery ceremonies all stay the same. What Dual-Track adds is a parallel discovery process that feeds validated work into your existing delivery pipeline. Engineering still operates the way it does now, but the work that reaches them has already been vetted with users and tied to business outcomes. Think of it as upgrading the quality of what goes into each sprint, not changing how sprints run.