Before Publishing That Product Roadmap
Before Publishing That Product Roadmap
Product roadmaps are in all shapes and sizes, and set expectats for colleagues and internal stakeholders. What to consider when building those?
Product roadmaps are considered to be strategic plans that define desired outcomes and highlight major milestones to reach those same outcomes. They tell a story while supporting higher-level product strategies, which are then the building blocks of a good product vision.
When creating roadmaps, organizations need to make several decisions that affect how their roadmaps will look like, what items they will contain, and who will be the primary audience for such plans.
Timeframe
The very first item organizations need to think about is the time horizon. While some businesses only plan for a couple of months ahead, others assemble their roadmap for the next years to come. There are three typical timeframes used for roadmaps.
A time period between 3 and 6 months: The best choice for small and medium-sized digital products or for companies in a highly competitive environment. Three to six months of foresight into the future might be just enough to plan a stable stream of discovery and development activities.
Planning for one year ahead: The choice for many established digital products with a larger user base and the preference of some physical brands that can iterate fast enough. This level of preparedness is needed to align R&D activities and budgets according to needs. In addition, in most cases, there is a necessity to communicate a clear direction where the product is heading to various stakeholders.
Forecasting for two or more years into the future: Used by industries where yearly changes are not possible and by organizations with 1000+ employees and multi-year planning. Some of these sectors include construction, manufacturing, and pharma, where research activities could take multiple years alone.
A ProductPlan research in 2018 found the average roadmap timeframe to be nine months, based on input from 500+ product managers. They also noted that in software development and healthcare, the majority of the respondents kept a roadmap for 4–6 months, while in other surveyed industries, the top choice was one year.
Granularity
Beyond timeframes, granularity indicates how precisely the delivery date of features can be determined. Some teams choose to make monthly feature promises while others abandon most time indicators. There are four usual approaches, ranked by the level of granularity (from high to low).
Months: Features are scheduled for specific months, indicating when an item new will become generally available for users. This approach, at most times, helps commercial organizations by providing tangible and well-communicable deadlines. On the other side, this might put extra pressure on delivery teams as they’ll be working not only against technical challenges but also firm deadlines.
Quarters: New capabilities are planned for fiscal quarters (Q1, Q2…), which are three-month periods within a calendar year. Quarterly forecasts typically give more flexibility for development teams than monthly ones while still having the benefit of communicable timeframes. One thing to keep in mind is the cone of uncertainty, which describes that the deeper a team is in a development, the more precise estimation they’re able to give.
Years: Not a common approach for digital solutions, but some organizations are only providing yearly forecasts. This group includes industries where innovation cannot be quick or requires a significant amount of ramp-up time.
Sequencing: Often referenced as “Now, Next, Later”. This method doesn’t provide an exact time when a certain capability will be delivered, instead sorts items into three or more columns. In the three-column example, “Now” is what the team is developing currently and is expected to be available first. “Next” is what the team will focus on soon, and “Later” is grouping items that are the furthest away from being completed. Slack’s Noah Weiss gave an example of this approach several years ago, from which most of it is still valid today.
When deciding about the type of forecasting, one key consideration should be the maturity of the engineering organization. While companies can always choose to loosen their forecasts a bit, without a clockwork-like operation, it’s not possible to get monthly commitments, even if they’re needed.
Roadmap items
Now that we’ve got the timeframe and the forecasting covered, it’s time to decide about what items to put on the roadmap. Some people prefer to use features or capabilities, while others pin their themes or outcomes.
Features: The most straightforward way to sum up the advantage of new functionalities. While there are certain critiques against feature-based roadmaps, the majority of product organizations still tend to use them. Features compactly describe new capabilities, and they’re understood best by people familiar with a product. Features are also usually accompanied by a description, which gives them an additional level of detail. With this approach, it’s essential to avoid the trap of “feature factories”, when teams are only focused on building features instead of trying to solve real customer problems.
Capabilities: In contrast to features, capabilities do not focus on what functionality is present in a software (“Emoji support”) but rather what the user is able to do (“Add emojis to messages”). Capabilities start with a verb that indicates some kind of action — like create, share, mark, add or edit. The benefit of this format is an easier understanding of the added value, while the downside is longer sentences. Capabilities are similar to what IBM calls an experience-based roadmap, where goals are written after the phrase “our users can”.
Themes: Instead of merely putting building blocks to a roadmap, themes are grouping features to introduce key focus areas. These groups are helping teams to concentrate on fewer bigger items that would drive value for customers and create alignment internally. Two examples of themes are “easier user onboarding” or “faster first purchase completion”. When defining themes, it’s essential to have enough supporting evidence to create ones that would bring real user benefits.
Outcomes: Defines what customers would like to achieve in the future. The keyword here is “would like to” and not “are able to”. Outcomes suppose an organization knows the pain points of its target group and does its best to address them. Outcomes do not indicate how something gets done (feature hypotheses address that) but specify what is desired. Instead of putting “social login”, an outcome would be that “users can sign up in half the time”. Alice Newton’s guide on Mind the Product provides additional details to outcome-driven roadmaps.
The choice of what items organizations are putting on their roadmap will mainly depend on the size of the product, the amount of information that they want to communicate, and the audience. The best roadmaps are focused and easy to interpret. They filter out all the unnecessary information that is not relevant in a given context.
Format
The form of the roadmap will define how it can be accessed, and it is highly dependent on the intended audience. There are two usual formats; one is a static document, while the other is a dedicated website.
Static document: A corporate slide, a PDF, or just an image asset that is stored in a central place. With the current document editors, it’s relatively easy to assemble a roadmap, and there are many templates readily available online. The advantage of this format is flexibility. Static roadmaps can be inserted into presentations, used as an attachment, or can be just published online. The potential drawback here is version control. As multiple past editions might be circulating in the organization, it’s essential to label the document with a date or version number.
Dedicated website: Some organizations choose to build a specialized website to highlight upcoming developments. With a dedicated page, companies can provide a better narrative for their plans. This approach allows roadmap visitors to filter to specific subsections and explore more details about feature candidates. Keep in mind that a site like this requires an initial investment, so it may be only worth it for companies who actively engage in their roadmap communication.
Beyond the final form of the roadmap, teams must also think about the process of creating their plan. While this is not discussed in this article, several ready-made software solutions help to facilitate the process, including ProductBoard, Aha, Roadmunk, Craft, and many others.
Audience
The last key question companies need to tackle is the intended audience for their roadmap. Selecting the audience affects other vital points listed before, as there might be different requirements for external and internal stakeholders.
Creating it for external audiences: A roadmap for external stakeholders needs to provide a great overview of the direction a product is heading to. The customer-facing version should only include the level of detail that is necessary to present a convincing vision while avoiding any internal abbreviation or jargon. In the case of bigger products, an external roadmap might have several slightly different target groups, which should be taken into consideration when communicated. Not everything is relevant to everyone. Beyond that, roadmaps should only contain date commitments if there is a fair chance that they can be kept. Besides, these external-facing documents are advised to be updated every quarter at least, if not more often.
Assembling it for an internal audience: The requirements for an internal roadmap can be vastly different than the one before. First, it’s important to denote the exact stakeholder. There is a difference in what should be communicated to engineering teams and C-level executives. Internal-facing roadmaps aimed at delivery organizations help long-term planning and thus, go into deeper details. They include technical enablers, architectural changes, and might map out dependencies to support cross-team collaboration. In contrast to external roadmaps, internal ones are very dynamic. They constantly change as user stories are being completed and new information is being surfaced. Martin Suntinger from Atlassian listed ten tips for building great roadmaps for engineering teams.
It should be noted that not every organization chooses to publish an external roadmap. Laying out the cards can help users buy into a vision, but it might also tip off potential competitors. When building roadmaps for multiple audiences, start with the engineering teams first, only then develop one for external stakeholders.
Conclusion
Product organizations can get the most out of their roadmaps if they make the right decisions. These choices include deciding on the timeframe, the level of forecasting, the type of items, the format, and the selected audience.
Furthermore, no two companies are the same. The preferred options might be affected by industry, market position, key stakeholders, or even internal requirements.
The following message from HubSpot’s “What’s New” page provides a great example of how to set the right expectations for roadmaps:
“As we like to be transparent with our customers, we want to include a reminder that while we endeavor to continually develop our software, we do so in an agile way. This means that even our best-laid plans get adjusted. While we do expect to develop and improve our products, we can’t promise any specific features will be delivered on any specific timeline, including the features discussed above. We hope you’ll buy the product for where it’s at today and continue to see value over time. This means that you should not decide to buy based on a feature being made available in the future.”
Now go and get ready to spark the change!
Bonus: external-facing roadmap examples
Microsoft 365: Feature roadmap to a year ahead, quarterly forecasts mixed with monthly commitments for nearby items.
Atlassian: Capability roadmap to one year in the future, denoting only the year for the items.
Google G Suite: Feature roadmap forecasting the quarter ahead, status indicators instead of time commitments.
Twitter Developer Platform: Feature roadmap with an undefined timeframe, using an alternative to “Now, Next, Later” forecasting.
LinkedIn Marketing Solutions: Feature roadmap for around nine months, indicating fiscal quarters as delivery dates in their presentation.
SAP: Feature roadmap for 1–2 years, quarterly commitments mixed with yearly forecasts for further items.
Zoom Developer Platform: Feature roadmap with an undefined timeframe, using short, mid, and long-term forecasting.
Buffer: Capability roadmap with an undefined timeframe, denoting items in progress, exploration, and specifying excluded ideas for the time being.
Azure DevOps: Feature roadmap looking into a bit more than a year ahead, indicating delivery dates as fiscal quarters, mixed with “Future” labels.
HubSpot: Feature roadmap for the very near future, indicating “available” or “coming soon” items, without any exact date forecasts.