I like to think of myself as a box checker when it comes to a task list.
For example, I made some pretty good French toast this morning. I mentally ticked off the steps as I danced through the chaos of a Sunday morning kitchen with two toddlers running around “helping.”
Beyond the ingredients gathering and prep, had to remember that my son likes his French toast very well done, my daughter likes hers with minimal syrup, and my wife likes me to use coconut oil instead of butter in the pan.
Again, this becomes easy if you can keep a list of to-do’s handy. Whether they’re in your head or otherwise, simply strike through them as you handle each one. There’s a negative connotation to that sort of “box checking” thinking, but for tasks with multiple steps, it helps me organize my requirements into a coherent pipeline of actions towards an outcome that’s greater than the sum of its parts (see where I’m going with this?).
As a product manager, I also like to check boxes. My favorite one is saying “well, it depends” multiple times per day. When I hear the question, “what is a roadmap?” I have no choice but to say, “well, it depends!” If we take my French toast anecdote and apply it to product roadmaps, we can develop a few universal truths around what a roadmap is and isn’t. At the same time, we can maintain our flexibility to say “it depends” so we can tailor the roadmap as needed.
So...What is a roadmap?
Well, it depends!
I think of a roadmap as a tool for “organizing my requirements into coherent pipeline of actions towards an outcome that’s greater than the sum of its parts.”
You can think of a French toast recipe as a roadmap that never changes. The outcome is always the same (breakfast), the tactic never changes (French toast), the steps to achieve it are always the same (get the pan, prepare ingredients), and the requirements for my particular recipe are always the same (bread, eggs, vanilla, nutmeg, etc).
The timeframe is clear (30 mins of prep, 10 minutes of cooking), the impact is known (my kids will have a sugar rush but get a good portion of their daily calories and enjoy the meal), and I know my dependencies (my son likes it well done, my wife prefers coconut oil). Most importantly, I can share it with others, and it is crystal clear what I am trying to do, and how I plan to do it.
In the product world, your roadmap should serve the same purpose. It should communicate, clearly:
Which business outcome are you moving toward?
What tactic are you using to get there?
What steps are you taking to achieve the tactic?
If not this tactic, then what?
Do you need any inputs from other teams?
Regardless of the type of roadmaps you are creating, it should answer those questions. The key differences are the level of detail you communicate for the bottom three bullets (outcomes should always be communicated at the same level of detail).
I typically split my roadmaps up by audience - Thinkers, Doers, and Carers.
For each one, the answer to “what is a roadmap” never changes. Your job is to understand how to communicate the critical information that each type of audience needs.
Roadmap for thinkers
Bet you thought I was going to use The Thinker here!
This is my cute way of referring to folks who don’t want to get too bogged down by details.
Typically, this group includes executives and upper management, and in a B2B world would include the purchasers as opposed to the end users. This type of roadmap would focus on the high level steps needed to achieve my outcome, and what those steps mean for the business and customers as a whole.
Extending the breakfast metaphor further than it has any right to go, “Thinkers” likely already know that helping my family enjoy breakfast is a key business outcome for the year, and that a great tactic to achieve that would be making French toast. If they don’t, part of your roadmap needs to clearly and concisely state these items, and why. A Thinker roadmap also needs to focus on timing, but again, be high level.
Using the latter as a lens, the framing of a roadmap in this style might look something like this for a single entry:
In my experience, Thinkers respond to this level - it gives them a general idea of our product team outcomes and our reasoning behind them, it lets them know how we will go about it, what results we expect, what we aren’t doing because of this, and where we may need them to intervene with other teams to remove blockers.
And that last sentence is key to generating a positive response from Thinkers. They are strategic and want to remove blockers that are within their control, and in order to do that they need to know where we anticipate obstacles to arise. As product managers, any roadmap that is geared toward this group of stakeholders should include, as part of a conversation, why we anticipate blockers within the listed dependencies.
Thinkers are critical partners and can help you execute your roadmap if you provide the information they need.
Roadmap for doers
In the software world, we tend to think of the Doers as Engineering. After all, they are going to be the ones figuring out how the heck to implement our wild ideas, so it is critical we are clear with our requirements. While a roadmap is not the place for that, it doesn’t hurt to make life easier for this cohort of stakeholders.
In a world where our outcome is breakfast, the Doers would be the private chefs you hire to cook after you sell your patented French toast recipe for millions. The roadmap I show them would be:
Notice that most information hasn’t changed - the Outcome, the Why, the Tactic, and the Impact are the same because well, they are the same!
However, Doers need to know more detail about how to implement French toast, and giving them an expectation of time frame for delivery helps them understand exactly what they’ll need to do to get it done. Critically, the time frame also gives them the ability to communicate blockers to you as soon as possible.
And of course, it gives you the opportunity to make tradeoffs (we won’t use vanilla extract today because if we go to the store to get it, we will miss our delivery window).
Finally, the Dependencies information is more fleshed out, because by the time your Doers are evaluating the roadmap, you’ve had conversations with other teams whose information you are relying on to craft the roadmap, and Doers need this additional level of detail to implement the tactic in the way that satisfies these needs.
Carers and roadmaps
The only time to ignore stakeholders is when they say they don’t care, because they do.
Carers are basically the “Consulted and Informed” column of a traditional RACI document. In short, Carers are every stakeholder who might be impacted by what it is you’re doing, and even some who won’t be.
This is the public roadmap that I typically socialize with the entire company, and invite folks to provide questions on.
While the primary folks impacted are my immediate family, I would share this roadmap with grandparents, neighbors, the school - anyone who, at some point, might need to know how I think about helping my family enjoy breakfast, and why I do so.
Other roadmaps
No matter the type of roadmap you’re building - Outcome, Experiment, Objective, etc. - the basic framework I use remains the same. By gearing my roadmap models towards a specific audience, I am able to effectively communicate the what, why, and how of each tactic, and how those tactics roll up to outcomes. Adding the who has saved me countless back and forth meetings as well.
Ultimately, as long as your stakeholders understand what your team is aiming for, the type of roadmap becomes a matter of mutual agreement.
Bon appétit!
Adam Hecht
Read also
Build great roadmaps
