Product Roadmap First Principles

It’s Product Roadmap Building Time Again!

The end of 2020 is nearing, and it’s product roadmap building time again—at least for those companies that are still dedicated to the old command-and-control model. In the next few weeks, executives and (key) stakeholders will come together and define new functionality that they believe will meet business demands in 2021.

While investing in product roadmaps can yield a reasonable return by creating a shared understanding between the “the business” and product teams, I also believe that product roadmaps need to be living artifacts requiring continuous attention by everyone involved. To make that process as worthwhile as possible, adhering to the following seven product roadmap first principles has proven beneficial in my experience.

Update 2020-10-04: I added new content, a new graphic, and fixed some content debt.

🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.

First Principles of Product Roadmap Building—From Product Vision to User Stories to Roadmap Tools

In my experience, product roadmaps work best as an extension to the Product Backlog. While many practitioners believe that a roadmap is inherently a part of the Product Backlog created by its ordering, my experience has been different. From a pragmatic point of view, there are two reasons for keeping a roadmap separated from the Product Backlog:

1. An actionable Product Backlog contains work for three to four Sprints to avoid cluttering it and thus concealing signal within the noise of too many Product Backlog items. However, this time-frame is significantly shorter than the usual six to twelve months that a product roadmap covers.
2. It is essential to include a broader set of stakeholders in product development to create a shared understanding where the product is heading among all parties. This inclusion allows for continuous inspection, adaptation, and support. However, attending Sprint Reviews also proves challenging to stakeholders. Often, the level of discussion at the Review proves to be too granular, or the attending the event regularly demands too much effort on the stakeholders’ side.

Hence, an appropriate compromise is a continuously inspected and adapted roadmap, probably every six to twelve weeks, depending on the product, the organization, and the target market. In my experience, this approach has its merits if you keep the following first principles of product roadmaps in mind:

1. Don’t you have a product vision? If you don’t know where you’re going, any (product) road (map) will get you there. (The classic quote from Lewis Carroll works here, too.) Before you try to come up with a product roadmap, fix the vision problem first.
2. Don’t make epics and user stories a part of the product roadmap: A product roadmap is a high-level plan—based on what you know now—where your product might be heading. So keep epics and user stories out of the roadmap to lower the information noise. It’s all about the big picture.
3. List of features syndrome: By the way, a bunch of features does not constitute a product, and a list of features doesn’t make a product roadmap. Therefore, focus on themes, not features. A theme is a promise to solve a customer problem. It requires user research and you will need to identify pain levels, effort levels, and business values to prioritize your product roadmap. Focusing on themes shifts the attention from playing feature catch-up with competitors, pet features of individual stakeholders, and the dreaded “we know what to build” attitude to delivering customer value. (There’s a great post on that by Clémence Debaig, see below.)
4. Don’t confuse a product roadmap with a release plan: A product roadmap is not a release plan either. The roadmap is covering strategic planning for a year or two to come. The release plan is more likely to deal with the next two to six Sprints.
5. Don’t put dates in a product roadmap: Speaking of releases: Don’t put dates anywhere in the product roadmap. People will take any date in a roadmap for real: “You said Q3 and you haven’t yet delivered”. No stakeholder will understand or even be interested in the narrative why you haven’t yet delivered, for example, because of the cool stuff with higher customer value that you built in the meantime. And if you cannot avoid dates, then make the scope as broad as possible. (You can’t promise both date and scope at the same, that never works out.)
6. A roadmap requires regular attention: Roadmap building needs to be regularly exercised—not just once a year. Creating value for the customer is not about sticking to a plan, but being able to respond to change.
7. The roadmap tool question is overrated: You don’t need a tool to create a product roadmap. Whiteboards and index cards are just fine, as are Google Apps, Murals, Keynote, or Excel—whatever you feel comfortable with. The content of the roadmap matters, its presentation is secondary as long as all stakeholders buy-in.

Cannot see the form?
Please click here.

My Reading Recommendations:

Delve deeper into the roadmap topic with the following articles:

• Ryan Singer: Options, Not Roadmaps.
• Roman Pichler: The GO Portfolio Roadmap.
• John Cutler: “Vision” and Prescriptive Roadmaps.
• Marty Cagan: The Alternative to Roadmaps.
• Marty Cagan: Roadmap Alternative FAQ.

Conclusion

Product roadmaps can be an incredibly successful tool to create empowered Scrum teams with the respective stakeholders’ support. However, it takes little to cross the thin line back to command-and-control practices from the outdated industrial paradigm and misuse a product roadmap as a central planning authority tool. Beware of the signs that the before-mentioned first principles are no longer guiding the effort of creating a product roadmap.

Am I missing a “first principle?” Please let me know in the comments.

✋ Do Not Miss Out: Join the 8,000-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

📖 Related Posts

11 Proven Stakeholder Communication Tactics

28 Product Backlog and Refinement Anti-Patterns

Four Lessons Learned From Making Customer Value Your Priority

App Prototyping With Absolute Beginners – Agile Experiments

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.