The Road Map to Hell
A Deconstructive Approach to Road Mapping
March is almost over and I’ve yet to present my road map for 2019. It’s not that I don’t have it, or that my dog ate it. Nothing like that. In my head it’s all crystal clear. It’s anywhere else that it’s fuzzy. Like on my Trello board or on Jira Portfolio. Trying to find the best way to communicate it made me think…
Since I was a small child, I enjoyed breaking things apart, so here is my deconstruction of a product road mapping. It’s done with the best intentions and hopefully it will help me (and you) get someplace.
Starting from the top
“If you can’t explain it simply, you don’t understand it well enough”
Albert Einstein
Any road map communicates how to get from point A to point B.
In product management, road map communicates the future of the product to stakeholders.
TL;WR
To save you some time and effort going through all the rumbling below, here is the nutshell, so feel free to jump ahead and come back later.
Spoiler Alert
The solution to putting out a clear enough road map is to put out 2 road maps. That’s right. Double the work, half the effort.
The rest of this story will hopefully provide some reasoning and insights.
Inbound, Outbound
Since road maps are meant to be communicated, it is best to “write” them down in the language of the audience. That is why you should have 2 road maps. An outbound road map, meant to be shared with customers (but also those who speak to them e.g sales, marketing, support), and an inbound road map, meant to be shared internally with the development team.
What’s the difference you ask?
Outbound road map puts the Value Proposition on a timeline.
Inbound road map puts the Features Set on a timeline.
Features and value are not the same. a feature called “Available off-line” has a value proposition of “Continue your work even with no internet connection”. While from a PM’s point of view it’s the same, your sales team, marketing and customers would have a better understanding of the value proposition rather than the feature name.
Actually, you road map should have started with feature requests from sales, marketing and users asking for “access to my work, even with no internet connection”, but that’s irrelevant now.
Back to square one
Your road map should tell a story of how your product is going to get to wherever you want it to be, in a period of 12 months, or so. As suggested, it’s not only about added features but mostly about added value. This is tricky because it raises some very philosophical questions that can lead to very pragmatic conclusions.
If my product already delivers value, why should I invest in adding more features?
Routine wins over anything and what was, will be. If your dev team has 12 developers, they will continue to complete tasks and issues even with a blank road map. It’s just how it is.
So, no road map?
Your road map should be built to move the needle. If that is not the case, then no road map for you. You can stop reading and move on to lighter materials. I heard Mad magazine latest issue is hilarious.
Still here? Time to move on…
Way Points and Epics
On your journey from here to there, you should find comfort in small victories. These are like way points or short term goals. They should make your customer slightly more satisfied, or at least, make it easier for your team to deliver such value in the future. These way points can also be called Epics, but remember that your management team (and customers) might not know what the heck epics are, or way points. Short term goals will do just fine.
So, our inbound/outbound road maps have way points. Is that all?
Short Term, Long Term
Prophecy was given to fools. Long term goals on your road map are still made up of value you want to deliver, or better yet, your customers will be willing to pay for. With all honestly, do you know today what your users will want in 6 months? how about 9? or 12 months? If your answer is yes, forget product management, you’re an oracle— go buy a lottery ticket or open a fortune telling booth. So what to do with such long term goals? I honestly don’t know. Your internal stakeholders may want to know and you may be required to provide it, but it is futile. The only reason I can think of planning that far ahead is if execution takes a really long long time — like in hardware companies such as Intel, Checkpoint or BMW. In SaaS companies like the one I work for —long term is mostly guesswork.
Moving The Needle
So the road map should hold value that moves the needle? Easier said than done. That is why you’re the PM, to set achievable goals that will increase value in short time, helping your company stay relevant and profitable. You will need all your skills to get the road map just right and these tips might help you stay in focus:
Tip #1: Listen
Your customers are the best source (but not the only) of needed value, whether from pain points or feature requests, it’s a gold mine (who am I kidding, more like a needle in a haystack).
Tip #2: Don’t Listen
We all have a few customers who would buy if only you had it in mint green color. Send them to the competition. Not every voice should be heard and not every customer should be taken as THE VoC. Data analytics can really help you see things from a broader angle, filtering the irrelevant. Use data and VoC wisely.
Tip #3: Collaborate
The road map should be build in collaboration. Sales, support, marketing, dev and other stakeholders can provide you with insights (and feature requests) that can really move the needle. Use them in creating the long list, short list and prioritization. There are many ways to do it, just make sure your road map doesn't resemble the Tower of Babylon.
Tip #4: Be Decisive
As the product manager you hold responsibility for the road map. This means you should also have the final word. It might be the others think differently, but it’s not their responsibility and thus not their call to make. Collect as much data and feedback as you can but at the end of the day make a decision.
Tip #5: Be Agile
Be willing to change your road map as response to changes. It might be that your main algorithm engineer left or Google are no longer supporting whatever. These changes are part of your risk management, competitor analysis and of course the road map. If a change of course is needed, do it without hesitation.
Tip #6: Celebration Time
When your team reaches a way point, stop for some refreshments, even if it is not a major way point or there is still a long way to go. Use this pause to reflect on the road ahead but also analyze past sprints. Give credit when credit is due and pump up your team toward the next way point.
A good product manager fully understands the road map ahead and its justifications. A great product manager can show it.
Have your own tips to share? Use the comments below :-)
