After inheriting a weathered product roadmap whose years of wear and tear had been the source of chronic problems for our company, I decided to fortify its very foundation.
Like many early stage companies, we had been struggling with product direction, with making and keeping promises to customers, and with overall Engineering churn. The source of many of these problems was a Product Roadmap that frequently over committed and that failed to adhere to any consistent vision.
What drove this decision
It's fair to say that no one expects every promise to come true. And that holds for product roadmaps as well. Roadmaps are simply a plan that drives towards some future state of your product and as Eisenhower famously said, "Plans are nothing, planning is everything".
Some Product Managers get into trouble when they get too specific about future plans and end up prematurely commit to features and dates in their roadmaps. This was a perpetual problem at my company and over the years, our credibility with customers and prospects as well as with internal sales & support teams had deteriorated.
The change in leadership on the Product team presented me with an opportunity to address the problem head on but that would require some real road(map) construction work.
The decision: Repair the roadmap infrastructure
There are quite a few good sources on the Internet that describe proven techniques for constructing sound product roadmaps and bolstering product planning efforts. Indeed, the tactics described here are not fundamentally revolutionary. What is novel perhaps, is how, with a few straightforward changes to how we built and socialized our product roadmap, we were able to directly address and ultimately improve the Product team's credibility.
Plan of attack
We identified and committed to three changes (at least in this first phase of construction) that would yield the most value for our stakeholders. They are not mutually dependent and could be done in any order.
Use 3/6/12 months increments
We immediately dropped the former convention of spelling out exact release dates in the roadmap. Instead of prematurely committing to specific monthly releases, for example, we create a 3/6/12 month plan. Because our confidence was much higher in the short term feature enhancements, we described these in more detail on the roadmap. And we decreased the level of detail around features as we moved into the six- and 12-month phases.
This change shifted the focus away from specific dates and to the prioritization and staging of the work itself.
Create themes for prioritizing product decisions
Roadmaps that stretch out for months or years can be complicated and unwieldy for the newcomer. It is difficult to capture all the finer points of a Roadmap in a high-level, visual chart or to communicate all the thinking that went into developing it.
To make our Roadmap easier for others outside the Product team to consume, we introduced and described a few themes. These themes helped to visually connect different units of work so that the causal observer could find order in the abundance of features.
The themes helped our audience to better understand our decision process. For instance, we could show how when a particular feature on the roadmap aligned with multiple themes it was given higher priority over other features.
Separate commitments from candidates
There is another simple technique that roadmappers can employ to avoid making explicit promises, especially when facing increased uncertainty about the ability to deliver features far down the road.
On any/all external facing versions of your roadmap, you include a graph that has two opposite endpoints: Commitments and Candidates. The features about which you feel more confident, likely the ones you will tackle sooner, will appear on the Commitment end of the graph. The features that are further out in the future will inevitably be designated as Candidates on the graph.
While this tactic might seem obvious to you and your Product team, it will help to set the proper expectations with your stakeholders and help you stave off unproductive conversations around future roadmap commitments.
The impact
I published the updated Product Roadmap at the beginning of the year with these three improvements: 3/6/12 month timelines, high-level themes, and a commitment/candidate graph. And, while the changes were relatively simple, the outcome was significant. Product conversations with internal and external audiences were more focused. Our team spent less time explaining or defending our decisions and more time engaging stakeholders in productive dialogue about solving important customer challenges.
Look for more reports from theProductPath around product roadmaps, roadmap planning, and managing stakeholders here on PM Decisions.
After a year's worth of lessons learned from all the good and bad product decisions I made as my company's Head of Products, I recognized that I would need even more help from the larger community of Product people in the months and years ahead.
The Product Decision: Advance my own professional product capabilities and better address the expanding needs of my company by tapping into the rich pool of talent and experience all around me.