Dual Track: Continuous Discovery & Delivery
You might also like to read my post on ‘Breaking Product Discovery into First Principles’
Shoutout to the 270+ people who registered for the webinar on Dual Track: Continuous Discovery and Delivery last week!
I’m continued to be blown away by the reception to these webinars.
Like this absolute banger feedback post the event 🔥:
“These product management webinars are like gold mines of insight! Every session leaves me buzzing with fresh perspectives and practical tips. It's amazing how much you can absorb in just a short time. I always log off feeling inspired and ready to tackle new challenges. It's like a power-up for my product skills!”
For those who missed it, the recording is here.
Below you’ll find a write up on:
What is Dual Track (continuous discovery and delivery) and how does it work
Why you should move away from project discovery towards this model
The mindset that you need to make it successful
and common practices that I’ve found helpful
What you won’t find below but I covered in the webinar above:
Who does Discovery vs Delivery?
How much time should a team spend in Discovery vs Delivery?
Making dual track work for internal platform teams
How to convince leaders to invest in Discovery
and a few other things…
Ok. Let’s get into this week’s post!
What is Dual Track and how does it work?
Dual track is a term popularised by Jeff Patton for describing how effective product teams work.
The term comes from consultant, then interaction designer, Desiree Sy, in her 2007 article describing how her team was incorporating design validation within agile development.
As Jeff Patton notes in his post on the topic, “There are two kinds of work, and there’s no way around it.”
We have discovery work and delivery work.
The term dual track is used to describe (and visualize) two 'tracks’ of continuous work.
Product teams must continuously:
Discover opportunities and solutions, whilst also;
Delivering high quality solutions in a scalable way
Thus forming two tracks (or as some frame 3 tracks; Discovery, Design and Delivery).
Two tracks, one team
It’s important to note that this is not two separate teams.
A common mistake is viewing discovery and delivery as a linear process.
i.e:
“Discovery is focused on learning and coming up with a solution. We then deliver that solution.”
This mentality assumes that discovery is a silver bullet and its output is a solution that is guaranteed to work.
While discovery can increase our chances of success, it’s by no means a slam dunk.
As a fellow Aussie, friend and author Nathan Baird visualized neatly:
Credit: Nathan Baird, Methodry
Robert G. Cooper's research in his book “Winning at New Products” found that 1 in 7 ideas succeed when you start with the solution.
Whereas starting with the problem and following a design thinking and discovery process increases the chances of success by 2.5 times.
Yet that means still a 2.5 out of 7 success rate.
So, the odds have increased, but you’re still far from a perfect run rate!
Me trying to explain the pitfalls of project discovery in the webinar.
Working this way promotes a “project discovery" approach.
As we view discovery as an upfront activity that we do first before moving into delivery. Resulting in long discovery cycles - several weeks to several months even 😱
This is where companies get themselves tied up as they split off into a ‘discovery team’ and a ‘delivery team’, rather than giving ownership of all this to a single product team.
This 'project-style discovery' makes it really hard to do any form of dual track as we silo out discovery from delivery.
(more on why this split isn't ideal in the webinar).
Changing How You View Discovery
If the output of product discovery is not designs, then what is it?
To answer this question, first we need to define product discovery.
Product discovery is a de-risking activity.
We do this by applying research techniques to gain confidence that we’re solving meaningful problems in the best way.
Product Discovery is about reducing risk by doing research before building. So we have confidence that we’re solving meaningful problems in the best way.
If you’re interested in learning more about product discovery, check out this post (and video) where I break product discovery down into first principles and core components.
I use words like ‘confidence’ very deliberately here.
The output of product discovery for me is confidence, not designs.
As Marcelo Zucchelli remarked in the comments during the webinar:
“If the output of your Discovery is ‘a Design’, then you're doing WAgile, and you're prob a feature team...”
The output of product discovery is confidence. Confidence to make a decision (not a solution or designs).
Therefore, you only need to do discovery until you have confidence in your decision to either discard the idea or build the first small increment.
Note this is not the same as having confidence in the entire idea or solution.
Remember, we’re also continuously delivering.
Meaning that we work iteratively and incrementally.
And an increment doesn’t mean it’s live with customers or even a complete product.
We’re talking an MVP or a first iteration, or smaller!
We’re still continuously learning more and delivering at the same time - that’s the whole idea!
How does this look in practice
The funny thing is that agile development is also about reducing risk.
The difference is that we reduce risk by building iteratively and through increments so we can get feedback, learn, and adjust.
They both try to solve the same problem through different means.
One is through research. The other is through building something small.
Discovery = reducing risk by learning through research. Agile = reducing risk by learning through building. It's not an either-or
The problem is that we often think these are at odds or incompatible.
And this is the goal of dual track. To get the best of both worlds.
To achieve this we apply agile principles of breaking work down and working incrementally.
So rather than trying to do a big, multiple week discovery project, we break the problem down.
Rather than trying to do discovery on something really big like ‘redesigning the entire onboarding process to improve conversion’.
We may do a little bit of discovery, look at the data, speak to a few customers to determine which parts of the onboarding process have the biggest drop off and focus on solving that first.
Apply agile principles in discovery by breaking down the problem so we can work iteratively
This means that discovery has now become much smaller.
You're no longer looking at the entire onboarding process. You're now focused on improving one screen or part of onboarding.
We can then do a little bit of discovery, enough to build a first version.
And then a little bit more discovery on what a second version might look like and so forth.
Discovery for the first iteration and build that. And then again for iteration 2 and so forth
But it’s a bit more nuanced than this.
As you can probably tell, this isn’t very continuous. It’s stop-start.
Whilst better than 'project discovery' this is still stop-start, not continuous
Instead, we collapse it.
If you've effectively broken down the work into iterations, then there's likely a bunch of areas that you're dying to explore; they just didn’t make the cut for v1.
Meaning that you can begin discovering and shaping what v2 looks like in parallel to building v1.
Continuous discovery and delivery
This has the advantage of tighter feedback loops.
We can begin to get feedback even during development!
Feedback is then incorporated into discovery and added to future iterations.
This is what continuous discovery and delivery looks like.
But remember, we also bin ideas as part of discovery!
So more like this…
Remember that product discovery is about discovering what NOT to do, just as much it is discovering what we should do!
Dual Track Practices
Here are some practices that I’ve found help enable dual track to work effectively
Outcomes
It goes without saying but continuous discovery and delivery works best when there’s uncertainty and the product team must navigate their way towards an outcome.
Whilst you can still do dual track in an output and project world you definitely lose the main benefit as it’s more solution design and delivery, than discovery.
Dual track works best when we're outcome-oriented
Opportunity Backlog
Given there are two types of work - discovery and delivery - it’s often best practice to separate these into two backlogs:
an Opportunity backlog
and a Development backlog
Opportunity backlog vs Development backlog
Your opportunity backlog will contain opportunities that you are yet to do discovery on.
And just like any backlog, it should be emergent and constantly have new opportunities added and old ones removed.
As things graduate from discovery into delivery, they will be reshaped into stories for development in the development backlog.
Side bar: I’m actually a big fan of breaking your backlog into different classes of work like this - if you’re interested in learning more about that watch this video or read this post.
Product Trios
I dive deeper into this topic in the webinar, but one question I constantly get asked about is, “if it’s one team doing both, who is doing discovery vs delivery?”
Watch the webinar if you’re interested in my more detailed response but a common construct used here is product trios.
A product trio typically consists of:
A Product Manager
Designer
Tech Lead
The idea is that at a minimum, these team members should be primarily focused on discovery.
Now this is different than being solely focused on discovery.
Remember you're still one team.
Therefore, while the rest of the team’s primary focus will be delivery, they will still be involved in discovery occasionally.
For example,
They may participate in some customer interviews
They may be included in workshops like ideation, journey mapping, etc
They will be involved in discovery playbacks
etc
Equally, the product trio still participates in delivery.
For example,
The product manager might need to help unblock things, help with tradeoffs, or clarify direction.
The designer might need to make changes to the experience or UI due to technical limitations that the team encountered. They may also need to help create design assets.
The tech lead will review code, coach team engineers, help unblock things, and make technical decisions.
(neither are exhaustive lists; they’re common scenarios to illustrate)
Not Everything Needs Discovery
Now, while this may seem to flow neatly from discovery to delivery, that’s far from the case.
A common question I get is whether everything needs to go through discovery?
And I get this question even on things like bugs and other activities.
The short answer is no.
The long answer is to remember that discovery is a de-risking exercise. So you need to ask yourself whether this piece of work's risk (and uncertainty) is high enough that we may want to invest in doing some research before committing to building something.
Now, for small things like small UI tweaks, bug fixes, etc., the answer will generally be no.
The risk is low, our confidence is high and the time it would take us to do discovery would probably be longer than the time to deliver it, so why not learn that way?
Now, we need to be careful because this is not a ‘get out of jail free card’ where we can skip discovery most of the time.
Building, in most cases, will be the more expensive way to learn and the most risky.
Wrap up
To make this real, I almost fell into the trap of project discovery just a few weeks ago while working on the Community for Product Pathways.
A few weeks ago I started doing my discovery for a community I'm creating for Product Pathways.
A week or two into it, I started trying to design the perfect community. I had to kick myself and remind myself that the goal here isn't to design what the final community will look like; it's to gain direction and confidence.
So I asked myself - do I have enough confidence to build something small?
And the answer was yes!
So, I shifted gears and launched a private alpha of the community with a dozen product leaders and have been using that to continue to discover, learn, and refine the community - dual track in action!
I'm now looking to extend that in the coming weeks - so if you're interested in joining the beta, complete this expression of interest here or reply to this email if you're unsure and I'll happily send you more details!
So, I hope this gives you a flavor of how it looks and works in practice.
I also hope that you’ve taken away some actionable insights and ideas that you can begin to implement to make incremental steps towards this model - if that’s what you want to do.
If you haven't already, I recommend reading Jeff Patton’s post and Desiree Sy original article on the topic. There’s some great stuff that adds more narrative than what I have covered here.
Thank you to those who joined me live the other day for the webinar!
I can't thank you enough, truly. The support and reception for them have been amazing.
If you’re interested in finding out more about future webinars and perhaps joining live, sign up on ProductPathways.comor follow Product Pathways on Linkedin here.
As always, thanks for reading!
Top Posts
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…