By Justina Andrijauskaitė-Karpovičė, Director, Product Management Operations, AdForm
These articles have been written by the latest cohort of the Practice Makes Unperfect programme – a course that helps women find and finesse their public voices.
I have decidedly unhappy thoughts every time I have to create a product roadmap, and I’ve been making them for 10 years. For a while I thought I was the only one. The only product manager whose heart sank and energy zapped when it was time to put pen to paper.
But then in 2017 I attended the Mind the Product workshop on creating better product roadmaps by Bruce McCarthy and C Todd Lombardo, where we started by writing a “Dear John” letter to our roadmaps. A jolly group of Product Managers from around the world spent 30 min naming the things that made us restless, unsatisfied and truly unhappy in our relationships with roadmaps.
And my oh my, there were some strong emotions in the room! Despite the different companies we worked for and different products we drove, we were united by having to prepare roadmaps for stakeholders, and even more so in our common dissatisfaction with them. So, what have the poor roadmaps done to deserve such a lack of love? And what have we done to them?!
But first… a definition. Product Roadmaps take different shapes and sizes depending on internal company standards, the timeframe a roadmap is built for, and its audience. Nonetheless, there are several elements that every roadmap has:
- WHAT product changes are planned to launch, and time indication for
- WHEN you plan to launch them.
Product Roadmaps are typically used to communicate product plans so that different stakeholders i.e. company management, development teams and your peers can stay informed. Often clients too. On a very basic level, a roadmap is seen as a plan, and this is where the problems begin.
Once stakeholders see a plan of WHAT and WHEN is expected to come to life, they take it as a promise or commitment to deliver accordingly, and therefore are naturally inclined to hold you accountable. On the other hand, after my decade in Product Management I haven’t seen a single product roadmap that wouldn’t change.
My colleagues and I at Adform once decided to track the changes we made throughout the year, and compare the roadmap we planned in January with the one we delivered at the end of the year. The result? Only around 50% of initially planned items were delivered during that year, and only 20% in their original time frame.
A product roadmap that has not changed is a phantom of the Product Management world. It is non-existent. If you show me a year-long roadmap that hasn’t changed in any way, I’ll buy you a beer and eat a hard copy of this article while you watch. And I’m not talking about one of those 5-item public roadmaps that just say NOW, NEXT, LATER. This is just a marketing charade.
We must always plan for change. Changes in the market, customer needs, time-bound opportunities, development capacity, business and technical requirements, or simply discovering completely unforeseen things. Learning new information and making adjustments as you go ultimately leads to better product and business decisions. So where does the friction come from?
I believe it comes from the basic rudimentary human need to have a plan and stick to it. We all like to fulfill our promises and feel bad if we don’t. Product people are no different in that sense, but we also know that roadmaps are just a bad way to give promises. Most Product people should tell you that a roadmap is not a hard commitment, or a delivery plan, but rather a direction, an outlook, or the best intention based on the information they currently know.
While a roadmap as a “plan” is absolutely useless, employing it as “a statement of intent and direction – like a literal road map for travelling, it states a destination we’re headed towards and provides options of a path to get there” is essential, as C. Todd Lombardo points out. In the meantime the roadmap as we know it remains a Product Management standard, but its shortcomings and the need to reduce the friction has been a hot topic in the community for some time, surging a series of suggestions ranging from removing timelines, adding confidence and certainty bars to ditching the roadmaps altogether and replacing them with a combination of Product Vision and Business Objectives or GIST planning methods.
As much as we may love freedom and autonomy in our roles, frameworks are essential when so many stakeholders are involved. Instead of setting them alight, for now I’d like to give roadmaps one more chance. But we have to see some changes:
- The focus must be put on the WHY to state the direction and strategy by having a vision statement and clear goals
- The goals should speak of the outcomes we are seeking for as opposed to features and solutions to be released
- Timelines have to go, period. They are a source of trouble and conflict, instantly giving a roadmap the disguise of a plan.
- Move timelines and features out to delivery/release plans, which must focus on shorter periods to allow space for change, but give the needed details stakeholders crave.
With a new updated way of working (let’s be real: it’s about time!) not only will our lives get easier, but processes will be clearer, and perhaps even more productive. Updating these norms won’t just mean I no longer want to send my product roadmap on fire, but there’s every chance we could see beautiful fireworks happen between departments and planners: a much better result!
