I’m a big fan of the Dual Track Agile framework
But lately I’ve been thinking it could use an update 👇
🔹 What does Dual Track Agile do?
Splits work into two broad buckets:
A) Discovery Track
B) Delivery Track
This is useful because:
1) Separating discovery work paves the way for continuous discovery
2) Sets the team up for small, incremental releasing
🔹 So what’s the problem?
Not all releases are small and incremental
Dual Track doesn’t account for GTM coordination around major releases
Without this coordination, we can be dev complete and still have 2-3 cycles left coordinating with Marketing, Sales, and Success
Not only is this inefficient, requirements can change during this phase 🙀
One solution is to introduce a third track of work →
[enter Goto Market track]
◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆
While Discovery is focused on learning velocity and Delivery is focused on development velocity… the Goto Market Track is focused on release coordination.
Let's break them down a bit more:
🔍 Discovery Track
Inputs → opportunities, ideas, problems
Outputs → product requirements docs, test results, learnings, insights, design specs, prototypes, abandoned ideas
🏗 Delivery Track
Inputs → product requirements docs, design specs, prototypes
Outputs → releasable software
🚢 Goto Market Track
Inputs → product requirements docs, design specs, prototypes, releasable software
Outputs → press releases, help & support docs, product announcements, release planning & timing, talk tracks for sales & success, plans & pricing updates
◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆
🔹 How & when do we use the Goto Market Track?
Check-in with GTM folks early in Discovery to determine what coordination is needed for release. If anything is identified, start that work immediately! This way we don't cram it in after development.
If little coordination is needed, we can bypass parts of the GTM Track--i.e. we don't always need pricing updates
🔹 Who participates in the GTM Track?
Just as Discovery is highly cross-functional, so is the GTM Track. For a major release, everyone is involved in GTM. Sales is updating their demo decks, Marketing is preparing announcement campaigns, Success is updating their onboarding playbooks, Engineering is tweaking feature flags for a controlled rollout.
🔹 Doesn’t the “release coordination” work fit into Discovery & Delivery already?
I would argue that it *can* be peppered throughout dual track. However, splitting this type of work out into it’s own track is valuable for a couple reasons:
1) It recognizes release coordination as it’s own type of work, separate from discovery and delivery
2) It creates a lane for GTM stakeholders, and carves out space for them to share their thoughts early and often
◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆
Hope this is helpful or interesting! 💬 / 👍
Follow Andrew for more thoughts on →
#product #productmanagement #productdevelopment #agile #discovery #delivery #productdesign #ux #uxdesign
But lately I’ve been thinking it could use an update 👇
🔹 What does Dual Track Agile do?
Splits work into two broad buckets:
A) Discovery Track
B) Delivery Track
This is useful because:
1) Separating discovery work paves the way for continuous discovery
2) Sets the team up for small, incremental releasing
🔹 So what’s the problem?
Not all releases are small and incremental
Dual Track doesn’t account for GTM coordination around major releases
Without this coordination, we can be dev complete and still have 2-3 cycles left coordinating with Marketing, Sales, and Success
Not only is this inefficient, requirements can change during this phase 🙀
One solution is to introduce a third track of work →
[enter Goto Market track]
◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆
While Discovery is focused on learning velocity and Delivery is focused on development velocity… the Goto Market Track is focused on release coordination.
Let's break them down a bit more:
🔍 Discovery Track
Inputs → opportunities, ideas, problems
Outputs → product requirements docs, test results, learnings, insights, design specs, prototypes, abandoned ideas
🏗 Delivery Track
Inputs → product requirements docs, design specs, prototypes
Outputs → releasable software
🚢 Goto Market Track
Inputs → product requirements docs, design specs, prototypes, releasable software
Outputs → press releases, help & support docs, product announcements, release planning & timing, talk tracks for sales & success, plans & pricing updates
◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆
🔹 How & when do we use the Goto Market Track?
Check-in with GTM folks early in Discovery to determine what coordination is needed for release. If anything is identified, start that work immediately! This way we don't cram it in after development.
If little coordination is needed, we can bypass parts of the GTM Track--i.e. we don't always need pricing updates
🔹 Who participates in the GTM Track?
Just as Discovery is highly cross-functional, so is the GTM Track. For a major release, everyone is involved in GTM. Sales is updating their demo decks, Marketing is preparing announcement campaigns, Success is updating their onboarding playbooks, Engineering is tweaking feature flags for a controlled rollout.
🔹 Doesn’t the “release coordination” work fit into Discovery & Delivery already?
I would argue that it *can* be peppered throughout dual track. However, splitting this type of work out into it’s own track is valuable for a couple reasons:
1) It recognizes release coordination as it’s own type of work, separate from discovery and delivery
2) It creates a lane for GTM stakeholders, and carves out space for them to share their thoughts early and often
◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆
Hope this is helpful or interesting! 💬 / 👍
Follow Andrew for more thoughts on →
#product #productmanagement #productdevelopment #agile #discovery #delivery #productdesign #ux #uxdesign
