Summary: Listen to the Interview<br> <br> I’ve had some requests from listeners to explore product roadmaps, so I had a discussion with Jim Semick. He is co-founder of <a href="http://www.productplan.com/">ProductPlan</a>, which creates roadmap software for product teams.<br> 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.<br> In the interview we discuss:<br> <br> * The purpose of a product roadmap,<br> * Various ways roadmaps look,<br> * How roadmaps help product teams and organizations, and<br> * The best practices for constructing product roadmaps.<br> <br> <br> Practices and Ideas for Product Managers and Innovators<br> Summary of questions discussed:<br> <br> * 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.<br> <br> <br> <br> * 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 <a href="https://www.productplan.com/product-roadmap-templates/" target="_blank" rel="noopener noreferrer">here</a>. 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.<br> <br> <br> <br> * 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.<br> <br> <br> <br> * 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 no...
