Product Mastery Now

Helping product managers move to product mastery

By

TEI 094: Creating product roadmaps for product managers – with Jim Semick

Listen to the Interview

Subscribe: Google Podcasts | Stitcher | TuneIn | RSS

Product Manager Jim Semick

I’ve had some requests from listeners to explore product roadmaps, so 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.

In the interview we discuss:

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

 

Practices and Ideas for Product Managers and Innovators

Summary of questions discussed:

  • 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 tends and priorities change over time. You need to communicate to executives what is likely to change the farther 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’s not 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 ProductPlan 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 – its 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.

 

Useful links:

 

Innovation Quote

“There are no facts inside your building.” –Steve Blank

 

Raw Transcript

tei094

 

Thanks!

Thank you for being an Everyday Innovator and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.