Skip to content
Nerdy beta

Multi-Track Discovery & Delivery

Activity Product Management Team Topologies AI

Jeff Patton's dual-track model put discovery and delivery on one team so learning and building could feed each other. Now that a prototype costs an afternoon instead of a sprint, the number of tracks isn't the point — the discipline to run them is.

Origin

Dual-track ran two tracks inside one stream-aligned team: a continuous discovery track for research, validation, and experimentation, and an iterative delivery track for building and shipping. Patton was building on Desirée Sy’s agile usability research, and his point was never the number two. It was that one team should own both learning and building, because the two loops feed each other. That killed the classic handoff, where researchers write specs, developers build them a quarter later, and nobody discovers the idea was wrong until fixing it is expensive.

Change

Two tracks made sense when a working prototype cost a designer and an engineer a full sprint. It stops making sense when the same prototype takes an afternoon. Discovery no longer has to be a single queue feeding one delivery pipe. Every insight from a customer conversation or an assumption map can start its own thin track: frame the hypothesis, build the cheapest credible probe, put it in front of users, then kill it or promote it. That is multi-track. A handful of short-lived experiments running next to one durable delivery track that hardens whatever earns its way to production.

The constraint moves with the cost. Build capacity used to be the bottleneck. Now it’s the handoff from insight to experiment: how fast, and how honestly, a hunch becomes a test with a decision rule attached. AI makes the artifacts cheap, not the judgment about which insights deserve a track and whether you kill the ones that don’t earn promotion. The product trio stops crewing a single discovery track and starts editing a portfolio.

Challenge

Cheap tracks are easy to start and hard to stop. That is the whole problem. When a probe cost a sprint, scarcity managed the portfolio for you. Now nothing stops you from running ten half-alive experiments that all fight over the same five users. Multi-track only works if you supply the discipline that scarcity used to enforce for free.

  • Every track carries a hypothesis and a decision rule. A probe with no kill-or-promote rule is just a demo. Write down what result sends it into delivery and what result ends it. Do it before you build, while you can still be honest about the answer.
  • Cap the number of live tracks. WIP limits apply to learning too. Three or four running tracks is a portfolio. Ten is noise fighting over the same users.
  • Treat promotion as a real gate. Prototype code is evidence, not a release candidate. The delivery track rebuilds what the probe proved, at production quality, with the stream-aligned team owning the outcome. Shipping the probe because “it already works” is how you rack up the debt multi-track was supposed to spare you.
  • Make killing a track produce something. Log what each dead track disproved and feed it back into the opportunity space. A track that dies in three days is the cheapest learning you will ever buy, but only if someone writes down what it bought.

The teams still running classic dual-track aren’t wrong. Patton’s loop is intact. They’re just paying 2015 prices for learning that now costs an afternoon, and the backlog of untested ideas is the receipt.

Resources