Driver + Navigator
Hey I’m Ant and welcome to my newsletter where you will find practical lessons on building Products, Businesses and being a better Leader
You might have missed these recent posts:
- Great Product Managers Go Deeper
- Product Strategy Should Be Messy
- Product Discovery Should Speed Up Delivery, NOT Slow it Down
p.s. If you’re looking to grow your impact and accelerate your career, check out the Product Mentorship!
I love this model for clarifying roles and responsibilities because it's lightweight, simple, easy to use...and it works!
Inspired by the driver-navigator pattern from pair programming, I call it (you guess it!) 'Driver + Navigator'.
The way it works is rather than using a typical RACI or another roles and responsibility framework, we answer two questions:
Who is driving?
and, Who is navigating?
The 'Driver' is the person who is typically accountable for that step. They are the ones who are taking the lead and making sure things are progressing.
The driver is also often the decision maker. Now that doesn't mean that they're in command or the boss of the navigators. Like in pair programming it's a collaborative effort of two equals, not a hierarchy.
The Navigator(s) are those who need to either input, collaborate or contribute to the activity of phase of work.
The model is flexible and can be applied to almost anything.
I've used it for:
Workshops
Meetings
Tasks
and most commonly, Process.
A workshop example might look like this:
Driver = the person facilitating
Navigators = co-facilitators and maybe some other key roles
everyone else are participants.
To illustrate this working in practice, one of the navigators might be a senior stakeholder. Based on the conversation they suggest to pivot the agenda mid-workshop but it would still be down to the driver to decide whether to pivot or not. Maintaining the flow of the workshop.
I'm sure you're been there. When there is an opinion (or several) about where to take a meeting or workshop and you end up spending a chunk of time trying to come to a consensus.
In the driver + navigator model you would have a clear driver, it would be their decision.
As a navigator you can suggest and give input - after all that's why you're a navigator, because we value your input! - but you don't have the final say.
NOTE: If you do find yourself in that position during a meeting, a great trick I use all the time is to ask the question - just ask "Who's driving here?"
It's super powerful even if you haven't defined this up front. It really shocks the room into thinking "who isdriving?" and then assigning the necessary power to them. Which typically leads to "what do you want to do [driver]?" - unblocked!
Product Process Example
Here's an example of how it can look from a process perspective (and by no means is this THE only way to do things. It's simply how I've largely worked in the past).
If we 'loosely' break product development into 4 stages:
Problem: Choosing which problems to solve
Solution: Designing and testing solutions
Build: Building said solution
Release: Releasing and launching the solution to the market
The Driver + Navigator model can look something like this:
1. Problem
Starting with prioritising, setting direction and deciding on problems to focus on, this is typically a Product Manager's responsibility and therefore they would be in the 'driver' seat.
However, any good Product Manager knows they shouldn’t do this alone.
This is where the ‘navigator(s)’ comes in.
Whilst a Product Manager might be ultimately accountability for determining direction, product is a team sport.
It's hard to choose the best direction without the inputs of the experts around you.
In an effective product trio model you would expect to see product, design and the tech lead collaborate together here. Therefore I'd put the designer (or design lead) and the tech lead as 'navigators' for this step.
2. Solution
From there we start to launch into product discovery. Exploring and building our understanding of the problem space. As we start to progress from problem to solution (eg ideating and testing solution concepts) the reins would go to design to be the 'driver' of this step.
Again this isn't a handoff.
Product and engineering would still be 'navigators' at this step as they are key contributors to the solution. They may also have responsibilities to ensure that the solutions are feasible and viable. I'd also expect them to participate in concept testing and user interviews too.
3. Build
Continued into delivery.
We now would have engineering in the driver seat as they're the ones building the solution.
But again, you'd have design and product in the navigator seat to make scope and design tradeoffs if we run into feasibility issues.
4. Release
Finally when it's time to release (and I mean release to users not deploying code into production see this video for more on this distinction) the driver seat is handed back to product as go-to-market is a product decision.
But engineering and design (among other roles) are in the navigator seat because there's always design and technical considerations for releasing something.
I'd also add, if you have go-to-market roles like Product Marketing, they might be the ones in the driver seat here and product might be navigating.
Again this isn't supposed to be THE only way to do things. It's just an example of how I've largely worked in the past. You might have a whole suite of other roles like Business Analysts, specific stakeholders to consider, sales, customer success, etc. that might be in either the driver or navigator seat depending on the activity or phase of work.
In Practice
This is why I love this model. It avoids handoffs and silo work.
At every stage you should have at least one person driving and one person navigating, ensuring that we're working cross-functionally at all times.
I've introduced this at several different companies now, from small 50 people startups all the way to over 1,000 person enterprises, and it works surprisingly well.
I think it's because of its simplicity. You don't end up stuck trying to differentiate between what we mean by "responsible" vs "accountable" or trying to fill out some complex responsibility matrix.
Also remember that at the end of the day the goal isn't to have 100% clear boundaries and accountabilities. The goal is to have enough clarity for effective collaboration.
Hope that's helpful!
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…