What makes a great product roadmap in modern product teams?
Sure, many product teams claim to have roadmaps, but the artifacts often sit idle and fail to guide key decisions. What do teams put in roadmaps? Maybe you go to a doc with upcoming features, a detailed project plan? And a long list of pending roadmap items? Do these elements in a roadmap have any value to informing decisions in a rapidly changing landscape? Usually not.
We’ve established that all teams need roadmaps. Let’s now look at how teams currently develop and execute roadmaps.
If you’re looking for additional explanations or related guides, the TechPount homepage offers a clean starting point with regularly updated content.
The alignment problem that was hiding in plain sight
The traditional representation of a roadmap was a step by step process description of how a plan would unfold. Requirements would be collected, features prioritized, and the effort to deliver each one of them estimated. With the rules of the game clearly defined, a pretty roadmap is presented to stakeholders and/or investors.
With agile methodologies increasing in adoption, this way of organizing product development is no longer valid.Agile teams work differently.
Their iteration and pivot based on customer feedback is fast. Often their priorities change in the same week. This means their three-month product roadmap is already out of date; it served its purpose. There’s a large gap between how most product roadmaps are developed and how most modern product teams actually work.
Between the engineering-team struggling to deliver against one set of priorities and the product management-team constantly re-prioritizing the backlog. Between the sales-team knowing what their customers want but not what’s coming and when. Between the marketing-team correctly stating what they think will be released and the user-manual being too different. Between the product-manager informing customers of the new features or products and the CEO committing to a delivery date. Between the senior executives making strategic decisions that are based on bad assumptions and out-of-date information.
Many companies differ markedly between the plans and sales materials given to the Engineering organization (the people who will actually build the product) and those provided to the Sales organization. Engineering needs to deliver on commitments made to customers. Sales needs to communicate value to customers, and differentiate your product from competitive offerings. As a result, the information provided to each group is “filtered” in certain ways to support their differing goals.
The visual gap
Why do most communication failures happen? Because images (like a road map) are communicated via plain text (like a bullet point or table). We have all the tools to create feature relationships, dependencies, and timelines. We just don’t use them.
What do many organizations lack? Understanding of the connections between their initiatives. Seeing for each feature which other features it depends on, how delays in their area of the roadmap will affect other initiatives, and where they will need to invest resources to avoid conflicts. A product roadmap visualization tool provides just this insight and makes it immediately clear to all stakeholders.
Building roadmaps that survive contact with reality
A lot of us beat ourselves up about trying to predict the future, when in fact the real problem was trying to nail down too much detail about it. Too many specifics are solely for show since we can’t accurately predict them anyway (how long will it take to do something?). Improving time estimates is usually better than producing more of them. So a good roadmap isn’t an accurate map of the future. It’s a map of what you are willing to commit to discovering in the future.
Information is ordered first by time horizon (near-term, medium-term, long-term) and then by stakeholder group. Near-term initiatives have enough detail that engineering can estimate and commit to target release dates. Medium-term initiatives provide just enough detail that engineering can roughly sequence and commit to delivery of a coherent slice of function. Long-term initiatives provide just enough information for product management to know which themes to explore in discovery and for engineering to know which capabilities to build to best position the product in the market.
This structure allows us to be stable at the high level so we aren’t swerving every quarter, but more detailed on shorter horizons where we have a clearer understanding. Generally, the shorter the time horizon, the more detailed the plan should be.
The most valuable roadmaps are dynamic and flexible, so they are easily adjusted when new information becomes available. They are the most effective tools for communicating plans and product value to the entire organisation, as well as stakeholders outside the company.
The lifeline of our roadmap is adaptability.