Keep Your Roadmap Out of the Weeds and In the Mind of Your Team
As a project leader that works closely with product teams on a daily basis, the one tool that everyone needs and obsesses over is the product roadmap.
It’s your mechanism for getting alignment on your team and across your company. It communicates intent. It communicates priority. It’s the foundation for connecting your strategy with reality.
Roadmapping is a funny thing. They are kind of like belly buttons. Everyone has one, but if you look too close you are likely to find some “yunt ya”. That’s southern for dirt in dark places.
I’ve seen my fair share of them. Everything from post-it notes on a wall, to sophisticated spreadsheets embedded in wikis, to name your favorite roadmapping tool on the market.
None of them are perfect, but all of them are subject to the same core problems. I’m just going to focus on one of them today.
The Devil is Not Here
Roadmaps make teams debate silly things. One of those silly things is language. I’ve seen teams talk ad nauseam about the etymology of a word on a piece of paper.
Don’t get me wrong, words mean things and shared understanding is really important. But what ruins a roadmap is blocks of text that nobody understands for the sake of clarity. Teams air on the side of more is better.
If we can’t agree on a term, then let’s add more words. Yea, good idea, maybe that will help.
Teams also take advantage of time horizons. They build highly complex gantt charts with dependencies mapped out completely. They look beautiful too. A beautiful roadmap is not the goal.
The best roadmap with tons of detail actually ends up not being useful at all. The roadmap turns into a novel that no one reads. The product manager ends up getting invited to every meeting to translate.
People look at the roadmap, scratch their head and move on with their day. They find other ways to understand what’s going and continue to echo the call for a real roadmap.
The roadmap with the most detail and the most number of pages is not best. Roadmaps drowning in information ends up un-informing everyone.
It’s okay to simplify. It doesn’t mean you have nothing to work on; it promotes better conversations. Tell the devil he can look elsewhere in your documentation for the details.
Here are few tips for keeping your roadmap out of the weeds and in the minds of your team.
Good Enough for a Conversation
The goal with roadmapping is to be aligned on intent. You want your teams and your leadership to understand what you are working toward, why and what success could look like. Roadmaps get shared throughout a company and it’s hard to get to a level of fidelity that satisfies everyone. Here are a few tips that may help you simplify and overly detailed roadmap.
You should be able to put your roadmap on one page. Make it simple or you will lose your audience. If you are a product leader, challenge your product managers to get their roadmap on one page or less.
Refuse to look at it unless they meet your egregious request. Ok, that’s mean, don’t do that, but seriously ask for simple.
Three themes (or less)
Typically a team or set of teams is investing in something. What are those themes? If you are not sure, take a look at what your product team is named. Chances are you’ve named them according to what they work on. Probably not good if you have names like Team Grover or Team Hippo. The other place you can look for theme inspiration is in a team charter.
Keep in mind themes are gold for your marketing team. It will form the basis for their messaging and how they thinking about taking your stuff to market. Do them a favor and get that on your roadmap. You can thank me later for one less meeting.
Three time horizons (now, next, later)
Roadmaps communicate intent. Let me repeat that. Roadmaps communicate intent. Not dates. Use broader buckets for planning. This will help you avoid endless debates about when something will finish. Let your scrum master work on forecasting and delivery timelines. keep the date details out of the mix.
Six words, ideally a couple numbers.
If you can tell an entire story in six words, you can do the same for product roadmap intent. After all, what we deliver in product is how we are helping to change our customers lives.
Tell that story in six words or less.
Use numbers to share what you hope to move from to. You can use IDEO’s change statement as a thinking framework and then simplify from there.
We will change <present state> in order to <desired outcome>.
Details are great and helpful, but keep them out of your roadmap. Much detail brings many headaches in a roadmap. Instead, focus on building a roadmap that’s good enough for a conversation. Challenge yourself to follow these guidelines:
- Keep it to one page
- Capture themes
- Stay in three time horizons
- Tell stories