Creating Product Roadmaps- Valutrics

Innovators and product managers are familiar with quotes about knowing where you are going, such as…

If you don’t know where you are going, any road will get you there. – Lewis Carroll

Not knowing which road to take may be enjoyable for a spirited spontaneous road trip with friends, motoring to unexpected destinations. While this may be the makings of an exciting weekend, it is an unsettling notion when applied to innovation, product management, and business in general.

Products are created by taking steps to understand a problem customers are having, examining ways to solve the problem, determining a solution that provides great value to customers, creating a user experience customers appreciate, and more.

Successful products follow a path that is specific to the product. This path encompasses the features to build that create benefits for customers. The primary tool for charting this path, collaborating with a product team and senior leaders, is a Product Roadmap.

To examine product roadmaps and how they should be used, I had a discussion with Jim Semick. He is co-founder of ProductPlan, which creates roadmap software for product teams.

Jim has helped launch new products generating hundreds of millions in revenue, including being part of the founding team at AppFolio for property management, responsible for the requirements and launch of GoToMyPC and GoToMeeting (acquired by Citrix), as well as spending time at Microsoft.

We discussed several aspects of roadmaps, including:

The purpose of a product roadmap,
Various ways roadmaps look,
How roadmaps help product teams and organizations, and
The best practices for constructing product roadmaps.

Below is a summary of questions discussed followed by a link to the interview.

What is the purpose of a roadmap?

A product roadmap is used by most companies to communicate what they’ll be building over the near term and possibly over the longer term. It is also a tool for showing the product strategy, the why behind what they’re building. A lot of companies feel that the product roadmap is simply the backlog, but that’s not the best way to communicate the strategy. A feature list isn’t a product roadmap. The product roadmap needs to tie back to the strategy. A product roadmap is usually a visual document and communicates the why behind what you’re doing.

What do roadmaps look like?

They can take on different forms. It depends on the company, the type of product, and where it is in its lifecycle. Examples can be found here. Some startups, for example, use a Kanban-style roadmap, which is simply putting what you’re going to be building into certain buckets: what is planned, what is approved, what’s in development, and what’s been delivered. That’s a typical style for a smaller organization or maybe a new product. The more traditional product roadmap looks something like a Gantt chart, which is a timeline-style. It communicates what you’re going to build and the expected start and end date for each part of the work. Twelve months is a typical time-frame for showing what you’re going to build. But there are some caveats. For example, organizations moving to an agile development process may have greater uncertainty over a longer period. From a product manager’s perspective, showing a 12-month roadmap is a double-edged sword. On one hand, you want to communicate where you’re headed and inform executive stakeholders. But on the other hand, things tend to change. Competitors come on the scene and release different features, the market and the underlying technologies used can evolve, and of course, customer trends and priorities change over time. You need to communicate to executives what is likely to change the further the plans are in the future.

How do roadmaps help product teams?

A couple of areas are creating collaboration and setting priorities. Most product teams use some sort of mechanism to score and prioritize features. Some of them do it ad hoc — having a conversation about customer value, and maybe T-shirt sizing level-of-effort. The benefit of having a product roadmap and then also a mechanism to prioritize what goes on the roadmap is that you’re having the conversation to begin with. The roadmap becomes an important collaboration tool.

How much detail should go into a product roadmap?

If you’re an agile organization and you’re working in epics and stories,the roadmap should be at that epic level. Otherwise, if you’re at the story level, that is a product roadmap that is like a project plan. A good product roadmap brings it up a level where it isn’t project management-oriented. You’re not looking at man-hours, delivery dates, things like that. You’re looking at the bigger picture of what are you are going to be delivering beyond this month and this quarter.

What are the best practices for constructing and using roadmaps?

Begin thinking first about the product vision. It’s really important that product managers have a clear vision for the product. In many cases, the long-term vision has been handed down from senior leaders. The product manager’s objective is to see the product’s future in the context of the long-term vision. Then, from there, you get your strategies. The strategies can be longer-term goals like increasing customer success rate, improving customer satisfaction, improving growth, or expanding into new geographies. From a roadmap perspective, it’s important to tie back those strategies to the roadmap. So, one of the best practices that we’ve seen is to identify the items and how they relate to the strategy, in some sort of easily communicated manner, such as using color coding.

What are the benefits to moving to tools focused on roadmap creation, such as your Product Plan tool?

Let’s contrast it to static tools, like PowerPoint. During our own market validation for Product Plan, we discovered early on that product managers spend an inordinate amount of time making product plans look good. It’s their opportunity to show what they’re doing, their opportunity to shine. One of the values of ProductPlan is that it frees up that time. You’re not spending as much time in a template, trying to move things around and get them to look just right. With static tools, you create a static document. When the roadmap changes, you’re doing the work all over again. You’re creating different versions of that PowerPoint, sharing it with stakeholders, and trying to manage updates and who has the latest version. One of the benefits of a web-based product roadmap product is that you’re not needing to reinvent the wheel every time. It’s not the 2016 product roadmap and then you have this separate 2017 product roadmap. It’s just the product roadmap – it’s dynamic and current. PowerPoint is fine if you need to be creating an investor deck or you’re presenting to the company once per year. But if you’re moving quickly and priorities are shifting, you need a dynamic web-based tool.