Dual-Track Development Isn't Two Tracks

Posted by Anders Toxboe on July 11, 2026 · 11 mins read

---

Dual-track development is usually described as two parallel activities. Discovery helps us decide what to build. Delivery helps us build it. Product trios work in discovery while engineering teams work in delivery, and the two meet at planning.

It’s a useful model because it emphasizes continuous learning instead of treating discovery as something that happens before implementation begins.

But over the last few months I’ve become convinced that this model also hides the most interesting part.

The real challenge isn’t moving work from discovery into delivery.

It’s moving understanding through the team.

That realization completely changed how I think about dual-track development.

The goal isn’t earlier discovery

The sentence that unlocked it for me was surprisingly simple.

The goal isn’t to make discovery happen earlier. The goal is to make understanding happen earlier.

Those two ideas sound almost identical, but they lead to very different behaviours.

If the goal is earlier discovery, it’s natural to focus on refining backlog, writing better tickets and preparing work before engineering gets involved. Success becomes a question of whether enough work is “ready”.

If the goal is earlier understanding, the conversation changes completely. Instead of asking, “What should we build next?”, we start asking, “What does the engineering team need to understand next so delivery can continue without interruption?”

That shifts the focus away from artifacts and towards knowledge, and it reflects something I’ve repeatedly heard from engineers.

Recently, one of our engineers told me they wished they knew more about what they were likely to work on next. They weren’t asking for more detailed specifications or earlier tickets. They simply wanted enough context to begin thinking about the problem before they were expected to solve it.

That resonated with me because good engineering rarely begins when implementation starts. It begins when someone notices a pattern while reviewing another pull request, connects two seemingly unrelated problems, or realises that something learned last week might simplify the feature they’ll build next week.

That kind of thinking can’t be scheduled into a planning meeting.

It needs time.

Understanding accumulates and compounds

That observation led me to another realization.

Planning doesn’t create shared understanding.

Planning reveals how much shared understanding already exists.

If a planning session spends most of its time helping engineers understand the problem, then planning is doing two jobs at once. It’s creating context while also deciding how to move forward. Those are different activities, and combining them is one reason planning often feels much heavier than it should.

The reason is that shared understanding doesn’t suddenly appear during planning. It accumulates over time, but more importantly, it compounds. Every customer conversation, design sketch, technical discussion and product decision adds another piece of context. On their own, those pieces are valuable. Together, they begin to reinforce one another. An insight from a customer interview changes how you interpret a technical constraint. A design exploration suddenly makes sense because of something an engineer pointed out last week. A new technical discovery changes how you think about the customer problem.

That’s the difference between accumulating information and compounding understanding.

I don’t think the answer is earlier planning. I think the answer is creating more opportunities for understanding to compound before implementation begins.

A product trio doesn’t need to wait until Cycle Preview or planning before involving engineers. Instead, it can gradually expose the team to what it’s learning as understanding evolves. One week, the trio might share an interesting customer problem it has observed. A few days later, it might explain what it learned from interviews and why one direction seems more promising than another. Later, it might ask an engineer to think through a technical constraint before any implementation decisions have been made.

None of those conversations are planning.

None of them require commitments.

Each conversation simply gives the team another opportunity to connect ideas.

By the time implementation begins, engineers aren’t hearing the story for the first time. They’re hearing the next chapter, and the team can spend its energy solving the problem instead of first trying to understand it.

The trio grows shared understanding

Thinking about discovery this way also changed how I see the role of a product trio. I no longer think its primary responsibility is to prepare work for engineering. I think its responsibility is to continuously grow shared understanding across Product, UX and Engineering by reducing the next important uncertainty before it becomes expensive.

Sometimes that means involving an engineer in a customer conversation. Sometimes it means sharing an observation before there’s even a proposed solution. Sometimes it means asking engineering to think through a technical constraint while the product direction is still fluid. The mechanism isn’t important. What matters is that understanding continues to grow long before implementation begins.

That also changes the question the trio asks itself. Instead of asking, “What should we build next cycle?”, it asks, “What does the team need to understand next?” The first question tends to produce backlogs. The second creates the conditions for continuous delivery.

Discovery should stay just ahead

One concern people often raise at this point is whether this means doing more discovery and producing bigger backlogs. I actually think the opposite.

The purpose of discovery isn’t to answer every question before delivery begins. It’s to answer the next question that would otherwise interrupt delivery. That single word matters because it changes discovery from a batching exercise into a continuous one. Discovery doesn’t need to stay months ahead of delivery. It only needs to stay just ahead, continuously removing the next important uncertainty before it becomes a bottleneck.

That’s why I prefer thinking about a shallow runway instead of a deep backlog. A healthy runway doesn’t mean having six weeks of refined tickets waiting to be implemented. It means that if the team finishes today’s work tomorrow, everyone already understands the next problem well enough to begin. The team understands the customer problem, why it matters, the biggest product and technical uncertainties, and what the first implementation slice is likely to be.

That’s enough.

Notice what’s deliberately missing.

• Nobody has been assigned the work.
• The implementation hasn’t been designed in detail.
• Every acceptance criterion hasn’t been written.
• Understanding has moved ahead.
• Commitment hasn’t.

That’s an important distinction because understanding is cheap to revise. Detailed implementation plans are not.

Continuous collaboration builds continuous understanding

Thinking about understanding this way also changed how I see collaboration.

It’s easy to picture dual-track development as Product discovering while Engineering delivers. Discovery produces understanding and delivery consumes it. That still feels like a handoff, just earlier in the process.

I think a better mental model is two meshing gears. Many teams think of discovery and delivery as one gear handing work to another. Discovery finishes, delivery begins. Even if the handoff happens earlier, it’s still a handoff. Two meshing gears tell a different story. Discovery continuously reduces uncertainty while delivery continuously creates new learning. Each movement immediately influences the other. The goal isn’t to perfect the handoff. It’s to eliminate the need for one.

The best product work I’ve experienced didn’t happen because Product completed discovery before Engineering got involved. It happened because Product, UX and Engineering gradually built understanding together. What changed wasn’t who collaborated, but when they collaborated.

Instead of concentrating collaboration into a single planning event every few weeks, it happened continuously through smaller conversations as understanding evolved. Engineers gained context before implementation began. Product gained technical feedback before committing to solutions. Design evolved alongside both. By the time implementation started, the team wasn’t coming together to build a shared understanding. It was building on one that already existed.

Discovery informed delivery, but delivery also created new technical insights that immediately influenced discovery. Understanding didn’t move in one direction. It grew continuously across the team.

Continuous flow is the consequence

Once I started thinking about dual-track development in terms of shared understanding rather than discovery and delivery, a lot of familiar practices looked different.

I stopped asking whether discovery was far enough ahead. I started asking whether the team had enough shared understanding to continue. I stopped asking whether the backlog was refined enough. I started asking whether we had removed the next important uncertainty. And I stopped thinking about planning as the place where a team builds understanding. I started thinking about it as the place where you discover whether you’ve already built enough of it.

What surprised me most is that continuous delivery is no longer the thing you’re optimizing for. It’s the consequence.

When understanding accumulates and compounds over time, engineers rarely have to stop and rebuild context before they can move forward. Discovery continues reducing uncertainty just ahead of delivery. Delivery continuously creates new learning that feeds back into discovery. Planning becomes lighter because it builds on understanding that already exists rather than trying to create it from scratch.

We spend a lot of time optimizing the flow of work through product teams. I suspect the better investment is optimizing the flow of understanding. When understanding accumulates and compounds continuously across Product, UX and Engineering, flow stops being the goal.

It becomes the consequence.