What is a product roadmap?
You've started at a new startup, Fabrikam, which is building a new AI-powered fashion app. At Fabrikam, we have an MVP product but now we need to grow. We have to keep our product managers, engineers, and designers on task with specific, attainable goals. You've been tasked by leadership with developing a product roadmap to keep the product moving forward.
What is a product roadmap?
A product roadmap is a plan for your product. It's a strategic document that helps you plan for your product and its growth, and keeps your team on track in executing on that growth. It's what allows your Product organization and your Product Managers to know and report where you are, where you’re going, and what the steps are along the path.
A good roadmap is the "north star" for your product. It connects the long-term vision your organization has for the product with the operational and customer reality on the ground. From your roadmap, your Product and Engineering teams derive the list of work that they'll undertake—like the features you want to build for the product—and populate backlogs.
A roadmap is a living document. Its development is iterative and organic. It changes as priorities and focuses change; as the product grows, you learn what product market fit looks like, and you learn from your customers. A real product roadmap is never finished.
How often do you update your roadmap?
How often you update your roadmap usually depends on how mature your organization is. Early-stage startups like Fabrikam generally have roadmaps that range out 3 to 6 months and are updated monthly. A larger or more mature organization might plan quarterly with some less-stable future plans laid out for future quarters.
Who works on a product roadmap?
A great product roadmap is a collaboration between many partners across your organization. Owned and collated by your Product team, it draws on inputs from internal groups like Engineering, Support, Marketing, and Sales. It's driven by external data collected from your product, your customers, your competitors, your investors, and the market.
A good Product Manager is constantly gathering this data, validating it, and feeding it into the roadmap, then seeing how or if it impacts plans. The Product Manager also feeds in the outcomes of the ongoing work you’re doing, like whether the features you've built had an impact on metrics like user adoption, customer satisfaction, or whatever else drives your business.
The outcomes from our roadmap then become part of the inputs together with the continuous data gathered from the other sources, and combines to form an iterative, cyclical document.
A product roadmap is hard to build. It’s a balancing act of finding the right features to build, evaluating customer asks versus product goals, then applying the engineering and design resources you have available to you.
What does a roadmap look like?
The final form of your roadmap could be represented in many different ways. Sometimes, it's a wall of Post It notes in your office showing your plan for the product; other times, it's a spreadsheet or document or stored in a specialized roadmap tool.
What makes up a typical roadmap?
To build a roadmap, we work top down, from the least granular component to the most granular.
- Mission: Your reason for building the product.
- Themes: High-level components of the product; for example, "Acquire new customers."
- Milestones: Groups of time-boxed epics; for example, three months worth of work.
- Epics: Collections of user stories that often represent a feature; for example, Authentication.
- User Stories: User-centric stories that describe a requirement; for example, "Giving the user the ability to reset their password." User stories are usually collected in an epic.
This approach is recommended because the top-level components are closer to the mission and should be a logical progression of detail, easily rolled up and tied to that mission. The alternative, starting from the base and writing up a series of user stories, leaves a lot of space between your mission and its practical application. We find if you start with that base, you end up twisting the top-level components into the shape of the user stories and not vice-versa.