To the uninitiated or junior product manager, just starting out in the field, the product roadmap process is a seemingly mechanical process. What are we going to build, when are we going to build it, put it in some sort of pretty chart format and wham, bam you are done. In practice, it’s not that simple.
The Purpose of Product Roadmaps
Despite its central role in pretty much every aspect of a software or technology company, product roadmaps and by extension the product roadmap process, is often misunderstood. As we allude to later, the purpose of the product roadmap changes depending on your interests in the process but in aggregate, the purpose of the product roadmap is to achieve these goals:
- Connect the product strategy with the corporate
- Provide a guiding document for executing the strategy
- Get internal stakeholders in alignment
- Facilitate discussion of options and scenario planning
- Communicate progress and status of product development
- Help communicate your strategy to external stakeholders (including customers)
Although the practical reality is a little different, the product roadmap is tool used by product managers to shepherd a product to market. The actual complexity of the product roadmap process lays in the political and organizational aspect of the task.
This complexity arises for a number of inter related reasons:
- Confusing use of terminology within the product management literature with regards to product roadmaps.
- Oversimplification of the product management process with regards to stakeholder priorities organization dynamics.
- Mischaracterization of the product roadmap as a single document.
The purpose of opening this article by raising these issues before you may not even what a product roadmap is is to give you some perspective while interpreting the content in this articles and allow you to:
- Develop your own methodology
- Adapt your methodology to the communication styles of different organizations.
- Send the right message to the right audience in order to achieve your objectives with minimal frustration
Let’s tackle each of these points before diving into the nuts and bolts of product roadmaps
Confusing Product Roadmap Terminology
As we alluded to earlier, a good portion of the product management literature, be it educational or marketing material, is characterized by a combination of poor context definition and inappropriate terminology, leading to a poorly managed product roadmap process and your inability to reach your professional objectives as a product manager because if there isnt an agreed upon definition of what purpose a roadmap should server, how can there be an agreed upon outcome (D’uh, if you don’t know where you are starting from and don’t know your final destination, what good is a map)
Here are some examples of such confusing terminology used to describe the objectives of product roadmaps, directly from the developer of a popular product roadmap software, ProductPlan:
- Regardless of whether or not your title is “product manager,” your goal in developing your roadmap will always be the same: To clearly articulate where you’re headed, and to show your strategy to your stakeholders in a compelling way – ProductPlan Marketing Material
- The product roadmap articulates the necessary tactical steps to take to achieve the vision. – ProductPlan Marketing Material
- The primary objective of most roadmaps is to communicate product strategy. – – ProductPlan Marketing Material
Oversimplification of The Purpose Product Roadmaps
The confusing use of terminology often results in an over simplification of the purpose of product roadmaps in a one size fits all manner. Much like a hammer can serve many purposes depending on the situation (hammer, nail remover, paper weight, doorstop), the purpose of a product roadmap depends on your interest as a stakeholder and as such, the you need a different version of the product roadmap to meet your needs. In regards to the specific contents of a roadmap it is important to note that it is context specific and depends on the audience:
- You, the product manager: A communication tool that allows for the efficient management of stakeholders so you can bring a product to market
- Executive Level Stakeholders: High level strategic roadmap. These folks typically do not care how the sausage is made. The expect you to make the sausage. They do not even know what sort of sausage they want most of the time.
- Internal, Operational Stakeholders: More tactical orientation to the roadmap.
The take away lesson from the points above should be an understanding that the product roadmap is not a single document, but rather a communication tool which is a series of documents, each constructed a little differently based on the target audience in order to help you, as a product manager
Why Does Any Of This Matter?
Quite simply because when it comes to the scope of what is consider to be the professional domain of a product manager, there is a seeming contradiction between the accepted wisdom within the profession that the primary objectives of product roadmaps is to solve what is considered to be the largest professional challenge faced by product managers.
- The primary objective of roadmap documents is to communicate the product strategy.
- A secondary objective is to help plan and prioritize.
Historically, product managers typically report there are a number of organizational and operational challenges they run into when building and managing roadmaps, including :
- Struggles with communicating product strategy and prioritizing.
- Getting company alignment is an uphill battle.
As we pointed out a few sentences ago, you’ll notice that these two challenges are same as the two priorities of building roadmaps in the first place. In my experience, this paradox occurs because of the issues we illustrated earlier (confusing terminology and oversimplification) and sorting these out allows professionals to focus on the operational challenges of product roadmap including:
- There is rarely a single source of roadmap truth.
- The amount of time roadmaps take to update;
- Many executive facing roadmaps are updated monthly weekly.
- Executives want regular updates on the changing product strategy but are faced with inconsistent (or non-existent) roadmaps from the product team.
- They are not visually compelling.
- Software planning and development tools are:
- Too granular for the big-picture strategic discussion that needs to happen.
- Often “bottom up” and they assume you already know what you want to accomplish.
- Despite new tools on the market, most product managers still use presentation software, spreadsheets, and wikis to manage their roadmaps.
- Spreadsheets are great for organizing and prioritizing, but bad for communicating a vision.
- Presentations take time to produce and are static documents that are hard to share.
- Wikis and other documents are disjointed and hard to keep updated.
Product Roadmap Structure
Let’s get this out of the way and define what a product roadmap is not. It is not simply a modified gantt chart, a prioritized listing of features, specific resource requirements, man-hours, story points, or other details. Although closely related, these details are associated with execution of the product roadmap and best left with software developers and product managers
Almost every operating division of a company involved in building or selling a product, technology/engineering, marketing and sales needs a product roadmap to aid in over all communication including technology, architecture, and marketing roadmaps. Ideally, these roadmaps roll up together, providing an overview of the strategic plan. As we alluded to in a previous article Software Product Roadmaps, there is a dark art associated with building the product roadmap and that is that the most important parts of the roadmap, like setting the vision, strategic goals for the product, and getting alignment on these with your stakeholders, are the first steps to creating a successful roadmap, which depending on your seniority within an organization, may or may not involve you.
From your perspective as a product manager, with the objective of product roadmap activities is: to gain organizational alignment with different stakeholders so that resource and budget allocations can be planned in advance to enable effective execution. While not all components will be used when talking with different groups of stakeholders, the main components of the product roadmap consist of:
- A defined time frame,
- A solid understanding of market events or deadlines that will drive deliverables, such as the underlying sales cycle or product seasonality,
- Specific products, product capabilities, or themes phased over a period of time, and
- Associated development activities or resources impacted or required.
The internal product roadmap may also be the result of, or heavily influenced by the product definition and project plan activities for the current release. Very often, the desired scope of envisioned capabilities to be delivered, in the current targeted time frame, far exceeds the team’s human resources or budget, and so a prioritization exercise will be needed for what is delivered now—versus what can be deferred. Requirements prioritization may go so far as to further define a set of phases for future work, which becomes additional short-term and possibly longer term aspects of the roadmap.
You can tell the difference between an experienced and inexperienced product manager by they way they think of the product roadmap; anyone who has brought a product to market knows the product roadmap is a living document, subject to regular discussion, re-prioritization and re-estimation. So, in addition to capitalizing on the flexibility provided by the best product roadmap tools, experienced product managers make use of best practices to make the roadmap process run smoothly.
Product Roadmap Process: Best Practice Examples
Ultimately, the product roadmap helps:
- Marketers attract the right users.
- Developers build the best possible product.
- Corporate executives strategically allocate resources.
And with these objective in mind, before diving into the mechanics and tasks associated with building out the roadmap, let’s look at some best practices that will up your game .
Product Roadmap Process Best Practice Example #1: Know Your Terminology
Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.
Get comfortable with abused, confused and misused terms that are often used interchangeably. As we demonstrated earlier, terms like strategy, tactics and goals are used interchangeably. This happens because many authors and product providers attempt to write one size fits all books/literature and really do not provide you with much context.
The reality is that whether or not your roadmap is strategy or tactically focused really depends on the intended audience and as you read through these best practices, this should become abundantly clear. If you don’t apply this lens when reading product management literature or books, most of them end up sounding like repetitive gobbley gook that often contradict one another. Keep these definition in you mind when building and discussing roadmaps
Goal: Where you want to end up with your initiative, be it a product or service.
Strategy: The direction/plan/path towards the goal. A strategy focused product roadmap targets executives Some authors include goals as part of strategy. When working with products, you’ll often hear the term “product strategy“. The strategy roadmap is a visualization of strategic plan, a high-level visual summary mapping out the vision and direction of a product offering over time and communicates the “how” and “why” behind “what” you’re building.
Tactics are the action taken to support the strategy and are oriented toward smaller steps and a shorter time frame along the way. This is where the product roadmap comes in. They involve best practices, specific plans, resources, etc. This is the “what” of your building.
Product Roadmap Process Best Practice Example #2: Be Visual
A great salesperson knows two things about selling an idea:
- How to tell a story in which the product is the hero as
- Understand humans are conditioned to be respond best to stories
The take away from this is that the best roadmap is on that tells a visual story, so as a product roadmap process best practice:
- Make the roadmap a visual representation of the product vision
- Visually demonstrate how the product roadmap is tied to company’s goals.
- The roadmap must be persuasive and easily interpreted.
There are a wide range of tools used to make visually appealing roadmaps, ranging from PowerPoint and spreadsheets to specialized product roadmapping tools which are popular software options that make it easier to create visually compelling product roadmaps.
Product Roadmap Process Best Practice Example #3: Have a Key Person In Charge
When you work with roadmapping tools, you’ll notice that the most highly regarded tools have a high level of flexibility as maintaining timeline and deliverable flexibility is an essential part of product roadmapping. This doesn’t mean that anyone can modify the roadmap as it requires an individual to assume ownership responsibility, not management by committee.
I've searched all the parks in all the cities and found no statues of committees.
Product Roadmap Process Best Practice Example #4: Keeps Stakeholders Involved in Regular Intervals
As you’ll read in The Product Roadmap and Corporate Strategy: How To Connect The Dots and How to Use Your Product Roadmap As A Communication Tool, product roadmaps are primarily stakeholder communication tools, both during their initial creation and ongoing iteration; the intention is that they are shared with the product owner, executive and development teams. This means:
- Updating your roadmap daily to capture any market changes,
- New planning directions, added resources, or changes in priorities.
The benefits of regularly updating a roadmap at reducing internal friction is two fold:
- Keeps stakeholders informed, so they understand factors that account for your product’s progress or delays,
- Making stakeholders feel informed, so they stay bought in
Product Roadmap Process Best Practice Example #5: Different Roadmaps for Different Audiences
Emblematic of the issues surrounding most discussions about product roadmaps, is that they are cookie cutter and lack context, so you end up having conflicts over the definition of strategy vs tactics, so you end up not knowing what the roadmap should portray. The reality is that a roadmap is a series of documents.
Viewing the roadmap as a single documents leads to different parts of the organization using and abusing it. For example, if sales and dev team work from the same roadmap, sales might commit to a feature in order to close a deal without consulting the developers on timing or probability.
As the roadmap gains and maintains buy-in, you need to provide different stakeholders with the information they need for their job rather than dumping it all on them and hoping for individuals to pick out the information they need. Sorry to say, you need to spoon feed information to people for you to maintain control so you need to prepare different versions of the roadmap for the needs internal department and stakeholders based on their unique role, needs and concerns, for example:
- Marketing departments typically want to understand how product features will look and behave.
- Sales wants details about when the product will be ready for customers to purchase it.
- Developers want to refactor a large portion of the code base.
- External stakeholders need to understand potential cashflow implications.
- Some basic guidelines for modifying roadmaps for different readers.
Most importantly….remember that almost any attempt to set a date for something that’s outside a 1-3 month time horizon is both a strategic career and management mistake. These well intentioned estimates are bound to fail as there are so many variables at play. So a word to the wise, avoid publishing hard dates that could change and get used to speaking in terms of quarters or months. Don’t fall into the trap of specifying dates for anything that’s not already a work-in-progress or that isn’t well defined and well understood
Each of the following product roadmaps were created in Smartsheet, and display timeframes instead of specific dates.
Internal Product Roadmap: Created without dates but lays out specific tasks. Notice that this related to development of features related to tactics. Used mainly for internal stakeholders. If you intend to share with external stakeholders, you want your product roadmap to reflect sufficient details without any specific tactics/strategies you’re considering.
External product roadmaps: Shared with external stakeholders (company investors, industry analysts, customers, and the media). The goal is to telegraph your strategic thinking but leave room for change, innovation and responsiveness, without jeopardizing your financing rounds.
Product Roadmap Process Best Practice Example #6: Share Your Product Roadmap.
The primary reason you want the product roadmap to be visible to anyone in the organization is that product roadmaps represent the plan of execution against the company vision and strategy, and minimizes the amount of friction you will get pushing it forward and managing stakeholders
This is because product roadmaps organize and communicate a lot of information so you as a product manager doesn’t have to. This means that your road map has the opportunity to speak directly to external or internal concerns and paint a clear picture of your intentions.
To executives, the roadmap validates your product’s usefulness to a market that aligns with the organization’s strategic direction, and also proves that it enhances the company’s position.
To your development team, your roadmap demonstrates progress and fosters inspiration. And to other internal departments—sales and marketing—your product roadmap sets expectations about product benefits, its comparisons to other similar products, and the potential for conversions.
To external customers, a product roadmap shows that you value their input and care about their needs. By sharing a roadmap externally, you signal that their awareness is a crucial part of your product’s success, which increases the likelihood of purchase. Additionally, it’s an opportunity to engage with customers and emphasize your brand story.
When the roadmap is hidden, the narratives about where the product is going, when, and why, are now outside of the control of the product manager and directly in the hands of the rumor mill and office grapevine.
