Some of our clients have been asked by stakeholders to develop a product roadmap. If you are one of those product people who find yourself in a tense situation when asked to commit something in writing, I hope you will find these tips useful.
Where Tension Occurs
Stakeholders run product companies. These individuals are trying to run the business, and they necessarily need to know what the company is building and when it will ship.
Product teams are trying to figure out what to deliver based on the business objectives, and the needs of their customers and business constituents. Figuring out what to build usually occurs in the discovery phase.
Realistically, however, many companies have not planned for, nor do they have enough time/budget for, discovery. Still, stakeholders push for commitments from product teams. Naturally, when product teams are uncertain, they are reluctant to commit and tension occurs.
No Need to Boil the Ocean
Under conditions of uncertainty, writing a software product roadmap becomes a challenge. However, it need not become unnecessarily difficult to write. Keep in mind that a roadmap is a tool. It’s not a contract. It’s going to change as the product team’s vision adjusts based on learnings. It’s a living document intended to give the audience a view of the strategy and what the organization is trying to accomplish over time.
Defining a Roadmap
Broadly speaking, a software product roadmap is a framework for aligning the expectations of key business stakeholders, customers, and influencers about the product direction. The company’s strategic objectives inform and drive this framework. It documents future commitments the business is making.
Sometimes, stakeholders draft roadmaps and then give them to the product team to implement. More commonly though, the product manager creates this type of document with substantial support from the product team.
The purpose of a roadmap is to communicate product strategy in a compelling and attractive way for its intended audience.
Anticipating Common Challenges in the Writing Process
In my experience, product teams and stakeholders have a lengthy list of features that they think the business should deliver. In most companies, opinions are abundant and cheap to offer up. So, coming up with a list of possible features to release is not the hard part.
Uncertainty About the Solution
The hard part is predicting if we have the right solution to the customer’s actual problem. Will it provide value? Will it get used?
It takes a fair amount of time and planning to investigate potential solutions. Spending time in discovery will usually mitigate feelings of uncertainty. There’s more about the product discovery phase mentioned below.
Uncertainty About “Deliver By” Date
Software delivery is extremely hard to predict. Every product team I’ve been a part of — as a product manager/owner, or consultant — struggles with nailing down dates. Here are the three common reasons it’s difficult to commit to delivery dates:
- We learn along the way. Teams do not often accurately anticipate what will slow them down or speed them up.
- Changes in direction occur. Businesses can and will adjust their strategy.
- The project experiences scope creep. This happens when the project adds additional features and functionality without adjusting time, budget, or project resources.
The above reasons contributed to the growing popularity of agile software methodology. In agile practice, work estimates are a measure of difficulty and not of time.
Overcoming Roadmap Challenges
Below are some ways to overcome common challenges while writing the product roadmap.
Plan for product discovery.
The most direct way to combat feelings of uncertainty when writing a software product roadmap is to spend time in discovery. In product discovery, the team is trying to home in on the right solutions to build. In discovery, the team is trying to assess:
- Value
- Usability
- Feasibility
- Business viability
In Marty Cagan’s book Inspired, he dedicates several chapters to various discovery techniques. For more information about the benefits of product discovery, check out this article by my colleague Mike Marsiglia Startup Product Roadmap, Phase 1 – Product Discovery.
Don’t wait for 100% strategic alignment.
Strategic alignment happens when the goals and plans of each unit in the business align with the corporate strategy. Achieving alignment is an ongoing process that must be flexible as the business makes adjustments. Sometimes alignment is never even achieved, and this can be a big challenge when writing a product roadmap.
I don’t recommend waiting for complete alignment between the business units and the company strategy. Write a roadmap that communicates the product vision as it stands today.
Use the “Now” “Next” “Later” framework.
This method organizes delivery commitments into three categories based on an anticipated delivery schedule. Items in “Now” are the focus of current efforts and are intended to be delivered soonest. In the “Next” category are those that are described more loosely and that have a wider focus. Lastly, items in the “Later” category are, by definition, the most high-level, flexible, and broadly focused.
There are two main reasons I like this framework. It allows for wiggle room when defining what the features and outcomes will be after “Now.” Secondly, it allows the team to communicate the strategy in a visual way that doesn’t commit the team to hard dates. Lastly, this framework can apply to nearly any type of planning document, not just to product roadmaps.
For a good overview of a different roadmap structure, see my colleague’s post Hacking a Product Roadmap for Uncertain Circumstances.
Final Thoughts on Writing a Product Roadmap
Hopefully, this overview will help anyone take on the daunting task of creating a product roadmap. There are just a few more pointers to share:
- Roadmaps should sync with reality. This means that teams should update roadmaps often.
- They should steer away from describing actual solutions. Instead, they should communicate the desired outcomes.
- Format and presentation are important. Roadmaps should be easy to consume and geared toward the intended audience.
Lastly, there are some interesting discussions happening in product management espousing alternatives to traditional planning tools like roadmaps. Check out some of these thought leaders if you are interested: Marty Cagan, Silicon Valley Product Group (mentioned above), Jeff Patton (creator of User Story Mapping), and Itmar Gilad (veteran product manager at Google and Microsoft).