MProduct <Education>: Creating Product Roadmaps

Edwin Mui
MProduct
Published in
7 min readNov 12, 2019

Welcome to MProduct Education. The primary function of this biweekly series is to consistently provide aspiring product managers (PM’s) with tools that can be used throughout their career as a PM. Whether you have just learned the operating functions of a PM or are well into your career within the realm of product, our educational content will always be created for those hungry to push their boundaries of PM knowledge.

This piece’s focus: Product Roadmaps

What is a Product Roadmap?

There are always going to be very nuanced answers when it comes to this question. In part, it is because there is no one definition that is able to capture all of the unique iterations each company or scenario might offer. However, after compiling different definitions that we found from multiple product managers in the industry, we crafted our own meaning that we believe captures it best:

Within an organization, a product roadmap is a strategic document that provides a direction for the development of a product by telling a story.

Product roadmaps are a way for product managers to explain to people the why, when, and how they are developing a product. Furthermore, a roadmap will differ depending on whom it is created for. Product managers will present to many different audiences depending on the scenario. For example, they may explain their roadmap to internal engineers and designers, while they may also present to external users and stakeholders. An engineering team will want to know all the technical details of a product, such as its features and requirements, while key stakeholders will want to understand how the development of X product will contribute to the overall growth of the company.

We will not get into the nuances of different roadmaps in this article, but there are some great articles that we have listed in the “References” section at the bottom of this article that will explain them in depth.

What does a roadmap normally consist of?

I. The Why

Why are we developing this product? That is the question we want to answer. At its core, a product roadmap is a story — it communicates the narrative behind the development of a key product, feature, or idea. If the development of a product was like an object traveling across a conveyor belt from the entrance of a factory to its exit, think of the roadmap as a visual image of what you would see if you were an airborne bird peering down from a hundred-feet up above. A roadmap is, quite literally in this case, a bird’s-eye view of the development of a product. Product managers use roadmaps to visually describe their reason for creating this product at this time for these people in this way. These are questions that PM’s consistently ask themselves when creating the document. Here is a great example that product management software company ProductPlan illustrated on their website:

As you can see from the above roadmap, every task is color-coded with a reason that is indicated by the legend on the right side of the screen.

II. The When

Of course, a roadmap is also a timeline. It explains to its audience when they can expect the release of certain features or updates. When setting deadlines on a roadmap, there are many mixed opinions about whether to include physical dates. We agree with agile product management expert Roman Picher, who says that dates are tricky, but should follow a general guideline. Typically, roadmaps include specific dates when being shown to internal teams, who need to know exactly when a product must be released. For example, a group of developers looking at a roadmap should immediately understand that smartphone would need to be released in time for the Christmas e-commerce season. On the other hand, we as product managers sometimes create roadmaps that will be shown to our customers or users. These roadmaps typically come in the form of marketing collateral that keeps our users engaged with our product. In this case, “hard deadlines” should probably be avoided, Picher says. One critical clarification to remember is that a roadmap is not a step-by-step operational plan. Though it provides a tentative overview of when certain milestones should be accomplished, its goal should ultimately be to provide high-level direction for the development of a product.

III. The How

Lastly, product managers need to explain how an organization will use different resources in order to successfully develop a product. They need to include which teams are going to work on what component of the product, and what kinds of tools they will use to do so. In various cases, the PM may also have to identify and communicate the costs of developing the product, speak with the head of finances, and then re-budget if needed. Of course, remember once again that the roadmap should not go into the granular operational details of how the organization will execute this development. We can think of the roadmap as the framework for product development, while an operations plan as the document that illustrates the step-by-step actions taken underneath the framework.

Initially, developing a roadmap may seem challenging. There are a lot of moving parts to take into consideration when doing so. Therefore, we have created an easy 5-step method of making one:

1. Identify the why, when, and how.

Using the principles we discussed in the previous section of this article, PM’s should first identify the core reason for why they are developing something. A new feature or update is supposed to always provide new value for its users — what kind of new value are we creating? After answering that question, we can then answer when and how we will go about executing that.

2. Think about the big picture.

Product managers should always center their roadmaps around high-level themes that will drive the development. These themes are broad ideas within a company that the new product will contribute to. PM’s should think about a few themes that they want to develop the product under, and then prioritize certain features based on those themes. David Cancel, the CEO of Drift, says that as a rule of thumb, he would create 3 themes for a fiscal quarter, and then prioritizes feature development based on that.

3. Think about the audience.

As mentioned earlier, a product manager will create slightly nuanced roadmaps for different audiences. If we are developing a plan for engineers, we will tailor the roadmap to engineers. External stakeholders will see something different. Same thing for our sales team. At the end of the day, we as product managers need to make sure we are always thinking about whom we are creating something for.

4. Value your time.

Between various calls, meetings, and individual planning sessions, product managers have very limited time in their schedules. Therefore, we as PM’s should understand that there are trade offs associated with developing detailed roadmaps. Our gut instinct tells us to make sure we need to have a perfect plan if we want to develop a good product, when in reality, the opposite is true. It is extremely difficult to predict the future, so we should be careful not to spend too much time perfecting the roadmap. In fact, in some cases, the same time we spent debating whether to build one product feature over the other could have instead been spent building both and then getting consumer feedback on which one to keep. This segues perfectly into our final step, which is:

5. Be agile.

Agile development is a commonly used term in product management, which is a method of developing a product in increments, where each increment improves the product just a little bit. This means that the product is always adapting to whatever will add the most value for the user. Likewise, the product roadmap will always shift as the product development life cycle continues. We must continue to remind ourselves that our roadmap is dynamic and treat it like a living document. Poor product management results in static roadmaps that are difficult to change over time.

Overall, product roadmaps are meant to communicate stories. They allow us as product managers to explain why, when, and how we are developing a product. Understanding how to develop a good roadmap is crucial to the product management role, as it is one of the most common tasks that we can expect to do as managers. In a survey conducted by experts at the “This is Product Management” podcast, around 76% of all the PM’s said that their main roles included setting the product roadmap for their company. This was the most common answer among all other tasks reported. Communication is an integral skill within the realm of product management, and the best PM’s understand how to use roadmaps as a medium to get their ideas across to both internal and external audiences. Roadmaps, when created correctly, will leave room for adjustment in the future while portraying a high-level, vivid screenshot of the current strategic vision for a product.

</Education>

As always, we are committed to creating the next generation of Product leaders and hope you will come join our MProduct community. If you want to keep up with what we are doing, follow us on Medium and LinkedIn, or check out our website here!

Go Blue!

References:

“10 Tips for Creating an Agile Product Roadmap.” Roman Pichler, 11 Oct. 2019, www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/.

“How to Create a Product Roadmap: TIPM.” This Is Product Management, www.thisisproductmanagement.com/blog/product-roadmap/.

“Introduction to Product Roadmaps.” Product Roadmap Examples and Definition | Aha!, www.aha.io/roadmapping/guide/product-roadmap.

Theus, Andre. “Building Your First Product Roadmap from Scratch.” Product Roadmap Software by ProductPlan, Product Plan, 29 Oct. 2019, www.productplan.com/building-your-first-product-roadmap/.

--

--