Dual-Track Agile

---

Origins

The dual-track pattern was popularized by Marty Cagan and Silicon Valley Product Group¹ and developed in parallel by Jeff Patton². Both were responding to the same problem: Agile teams that had become very good at delivery were still building features customers didn't want. Sprint after sprint of validated execution was producing well-engineered software that missed the market.

Cagan's diagnosis was structural. Discovery — the work of figuring out what to build and whether it would actually succeed — was usually compressed into a few backlog refinement meetings, or pushed off to a separate "discovery phase" that ended before delivery began. The team needed discovery and delivery to run continuously and in parallel, each feeding the other. That continuous parallel structure is what dual-track Agile describes.

The Two Tracks

Dual-track Agile is not a framework. It is a pattern for how a single cross-functional product team allocates its time and attention.

The Discovery Track

The discovery track answers four questions about each potential opportunity:

• Is this valuable? Will customers want it enough to buy, use, or recommend?
• Is this usable? Can customers actually figure out how to get value from it?
• Is this feasible? Can the engineering team build it with the time, tools, and skills available?
• Is this viable? Does it work for the business — legal, financial, brand, support?

The track is fast, lightweight, and experimental. Its outputs are validated learnings, prototypes, and small experiments — not specs. Items don't reach the delivery track until they've cleared enough of the four risks.

The Delivery Track

The delivery track is what most teams call "Agile" — sprints, daily standups, working software, definition of done. Items entering it have been validated in discovery. The track's job is to build them well, ship them, and instrument them so the team can learn from production.

Crucially, the delivery track is not a one-way pipeline. Production observations feed back into discovery: usage data, support tickets, A/B results, and customer interviews continuously re-shape what the team works on next.

How the Tracks Interact

Discovery and delivery do not run in isolation. They share the same team — the same Product Manager, the same Designer, the same Engineers — with each person spending part of their week in each track.

A typical week might include:

• Engineers spending most of their time in delivery, with one or two hours pulled into discovery for feasibility input on a prototype.
• The Designer splitting time roughly evenly — designing for delivery items in flight and prototyping for discovery items being validated.
• The Product Manager spending more time in discovery, with prioritization and backlog work touching both tracks.

The team also has standing rituals that span both tracks: a weekly discovery review where validated items move toward delivery, sprint planning that pulls from a discovery-validated backlog, and reviews that surface what production has taught the team since the last sprint.

The Discovery Loop in Practice

Inside the discovery track, items follow a small repeated loop: identify an opportunity, generate ideas, prototype the most promising, test with users, decide whether to validate further or kill the idea.

The loop is fast on purpose. Most discovery items spend hours, not weeks, in any single step. Cagan's rule of thumb is that a product team should be running multiple experiments per week, not multiple per quarter. The compounding effect of many small experiments is what produces the team's discovery muscle — not the depth of any single one.

What Dual-Track Is Not

Several common misreadings turn the pattern into something that doesn't work.

• It is not two teams. A separate discovery team handing requirements to a separate delivery team is a return to waterfall in disguise. The point is one team, two tracks.
• It is not a phase. Six weeks of discovery followed by six months of delivery is not dual-track — it is sequential. Both tracks run continuously.
• It is not "we already do refinement." Discovery is more than discussing backlog items in a refinement meeting. It involves real customer contact, prototypes, and experiments that can fail.
• It is not just the PM's job. Discovery requires Designers and Engineers participating directly. Pushing it onto Product Management alone produces specs, not validated learning.

Common Implementations

Teams adopt dual-track in different shapes depending on context.

• Continuous discovery (Teresa Torres pattern): weekly customer touchpoints feed an opportunity solution tree; discovery happens every week, regardless of sprint cadence.
• Spike-and-deliver: discovery items live in the same backlog as delivery items, distinguished by tag or color. Spikes get capacity allocation each sprint.
• Dual backlog: separate discovery and delivery backlogs, with explicit graduation criteria from one to the other.
• Strategy-led discovery: portfolio-level outcomes drive the discovery agenda; the team runs experiments aimed at quarterly outcomes rather than reacting to ad-hoc requests.

Common Pitfalls

• Discovery becomes spec-writing: the team treats discovery as upfront design rather than validation, and ships polished specs that haven't been tested.
• Delivery starves for validated work: discovery slows down or is poorly resourced, and the delivery team runs out of validated items. Teams fall back to delivering whatever stakeholder shouted loudest.
• No real customer contact: discovery happens entirely inside the building. The team produces internally-consistent ideas with no external signal.
• Discovery items never die: every idea goes to delivery eventually. Without the discipline to kill failed experiments, the discovery track becomes a delay rather than a filter.
• Designer or PM overload: one person becomes the discovery bottleneck while engineers stay heads-down in delivery. The team has discovery in name only.

Coaching Tips

Make Discovery Visible

If discovery happens in someone's notebook, it isn't real. Put it on a board, in a backlog, on a tree — somewhere the whole team can see what is being validated and what is being killed.

Set a Weekly Customer Quota

Teresa Torres' rule of one customer touchpoint per week is a useful forcing function. Without it, discovery quietly slides into internal opinion-shopping.

Resist the "Discovery Phase"

Stakeholders will push for a discovery phase that ends before delivery starts. That's waterfall. Hold the line on parallel tracks even when it feels inefficient at first.

Kill Items Out Loud

When discovery proves an idea wrong, announce it. The team needs to see that ideas die in discovery — otherwise everyone learns that all roads lead to delivery.

Get Engineers Into Discovery

The single biggest predictor of useful discovery is whether engineers participate. They surface feasibility constraints early and often spot the cheapest path to validation.

Track Discovery Throughput

Count experiments completed per quarter, not items shipped. A team running two experiments per quarter is doing discovery theater; one running twenty is doing the real thing.

Summary

Dual-track Agile is the structural pattern that lets product teams stop building the wrong thing efficiently. It treats discovery as a permanent capability the team invests in every week, alongside the delivery muscle most Agile teams already have. The two tracks running in parallel produce a backlog that is shaped by evidence rather than by feature requests, and a delivery cadence that is sustained by a steady supply of validated, ready items.

The pattern is easy to describe and hard to live. It requires Designers and Engineers willing to spend time in discovery, Product Managers willing to kill their own ideas, and leadership willing to fund both tracks rather than only the visible one. When all three are present, the team converges on what works far faster than a delivery-only team ever could.

Back to Discovery & Validation