As Lewis Carroll famously said, “If you don’t know where you’re going, any road will get you there.” While this quote certainly wasn’t said in reference to digital products, it’s an accurate representation of the importance of product roadmaps.

A product roadmap is a high-level visual summary that maps out the vision and direction of a product over time. It keeps teams out of the tactical weeds and focused on delivering business value. Then defines the the “why” and a little bit of the “what.” A living document, it should be continually updated as product managers gather feedback from users, the product team, and align with business objectives. But many product people get hung up on exactly what level of detail vs. ambiguity is best for their product.

So, exactly how far out should your roadmap go? Well, it depends.

Three Factors that Determine the Length of Your Product Roadmap

Unfortunately, there isn’t an easy and absolute answer to this question. Like most aspects of digital work, the length of a product roadmap depends on several variables. I find there are three main factors that determine the formation of a product roadmap: organizational culture, product complexity, and release management maturity.

1. Organizational CultureIs your organizational culture one of innovation or predictability? If leadership values innovation, you may be able to minimize the length of your roadmap, since everyone will understand that experimentation is driven by freedom and flexibility. However, if leadership values routine and predictability, you may be forced to build your roadmap out further.

    

2. Product ComplexityThe complexity of a product also influences the length of a product roadmap. A simpler product—such as a small app—may allow for a shorter roadmap, whereas a more complex product—like the brain of an airplane—will require a much larger scope.

    

3. Release Management MaturityFinally, release management maturity refers to the difficulty level of releasing software. If it’s easy for a team to release software, stakeholders will expect them to do so often—experimenting, learning, and iterating from each feature. Operating in a lean manner like this will result in a short-term roadmap and more flexibility further out in the timeline.

    

However, if releasing software is hard, they’ll do so more seldomly.  If releases are seldom, stakeholders will likely need a longer roadmap since they only have so many chances to see the shipped product. In this classic overview, Henrik Kniberg shares some approaches of mature release management.

Why you should organize your product roadmap by themes

The biggest risk in software is building the wrong thing. Therefore, the danger of building a roadmap too far out in advance with too many specifics is that you’ll tend to organize around what you promised you’d do, rather than around execution of what matters. In fact, I actually counsel product managers to be vague when building product roadmaps. To do so, we use broad themes, rather than promising specific features. Focus primarily on the “why” and leave the “what” and the “how” to the talented product development team.

Why? Because, as you know, software products tend to change rapidly over their life cycles. Organizing by themes gives roadmaps structure, but protects teams from overpromising and under-delivering.

Themes are a strategic guide or hook that convey your vision in a compelling way. Communicating strategic or financial value before diving into features is the best way to gain buy-in from leaders and stakeholders.
I encourage product managers to plan no more than one to two quarters ahead. The farther you plan, the more likely your value proposition will change. Instead, stay specific about the next six weeks.
Leave the “what” and the “how” to your team’s innovative minds. This approach also works for leaders who ask for six-month roadmaps.
It supports their big-picture needs while giving you freedom to adapt as the product evolves.

Schedule Meeting with an Augusto consultant.