The product management job has, at it’s core, a simple objective: get the most successful product out the door as fast as possible, then learn, then repeat. In this series we tackle how to become a great product manager by getting your product out the door. In this first installation, I tackle how to build a product roadmap. We’ll keep explanations as simple as possible while offering tactical advice based on experiences had launching products in the marketplace. If you’re looking to become a product manager, or wanting to hone your skills to stay fresh, this is the article for you.
Before starting on your product roadmap
Some pre-requisites and clarification before diving in. A product roadmap is the core deliverable document for the job (any organization that tells you different probably indicates the role is not quite product management. For more information on other product management role skus and how they can be dangerous you can read my recent post on the subject). So when starting in a new product manager job or applying for a new job keep this in mind that everything you learn and everyone you meet will be providing information that will ultimately feed your product’s roadmap.
The roadmap is foundationally a basic codification of the conversations you’ve had with stakeholders and vision for the next phase(s) of your product. Your document needs to illustrate your high level vision and objectives and the plan to accomplish your goals based on the two main restrictions in any organization, limited time and money. Every company has fixed resource and more they want to do than time and money to do them.
The product manager role is to go into these organizations and work with diverse and cross function inputs from business teams, marketing, data, leadership, other product, etc to create a clear prioritization for what can and should be done when. The roadmap is the distilled output of these conversations and will describe, after research with the teams that will actually build the product and enhancements, what can be done when. Once that is signed off by all stakeholder parties the document becomes your north star to work towards. It doesn’t mean you have to hit the dates, but it does mean that unless otherwise told you are building to that as your map. Your treasure map to success, promotions and glory!
Now, the roadmap seems like a powerful document. And it is. However, I want to take time to emphasize that dates will be a basic requirement that every leader will require of you to have in your document. By far the #1 painpoint I see with product managers and roadmaps is leadership thinks a date is firm when it’s not and miscommunications ensue and commitments are made by leadership to other leadership, etc.
The advice I give is to pre-empt this issue by clearly stating up front that dates are estimates. You can’t be held responsible for shifts in resources/organization/priority that may happen and change timing. Leadership will be receptive to this openness, and in return you can also make it clear that you will let them know if there are shifts on your end as new dependencies are uncovered, platform impacts, or other discoveries that will impact the launch dates.
Transparency around dates to stakeholders is crucial, as these groups also have goals that they are tracking to and rely on you completing the work to which you’ve committed.
One final caveat, there’s absolutely no “right” way to create a product roadmap. The roadmap document is meant as a guide for you and your organization to all align on and ensure everyone is on the same page. Like writing code, there’s not one true way. Rather, there’s tons of great approaches, and as the product community as a whole continues to iterate and grow these documents get better and clearer. So, use this article as a guide to one approach that you can use and riff off of in your own work.
There’s a lot that’s been written on the product roadmap, massive amounts in fact. It can be daunting to sift through all the noise for the great nuggets of wisdom. So we’ve created a list of our own favorites that serve as a crash course in building a roadmap that provides great additional perspective
- Mind the Product | Effective Product Roadmaps
- Roman Pichler | 10 Tips for Creating an Agile Product Roadmap
- Pragmatic Marketing | Creating the Right Product Roadmap
- Melissa Perri | Rethinking the Product Roadmap
- 280 Group | How to Create Product Roadmaps
- General Assembly Blog | How to Build a Brilliant Visual Product Roadmap
Ok, now that we have all the great background on the who, what, why of making a product roadmap let’s go through step by step what you will need to do to create one of these documents!
Step 1: Understand your product’s universe
This one sounds big, and it may be a bit of hyperbole, but I want to get across that in order to make an effective roadmap the first step is to understand two things. First, you need to understand the needs from everyone involved, and second understand what your scope is as a product manager.
Understanding the needs from those who have a stake in your product will require leadership support to make sure that you have a list that includes everyone. The last thing you want is to get your product roadmap built and some stakeholder that was left out in this first step raises a red flag and prevents you from moving forward because they want to go back to the start and discuss how their initiative will be included.
Once you have a list of stakeholders start meeting with each stakeholder or group and ask them about their needs and expectations to get a sense of how they may fit in the backlog. Ask them for anything they are expecting prioritized for the next 6-12 months, and let them know that they should send new items that come up to you. As part of any backlog item they should have a business case and data supporting why their feature needs to be built. This should either have already been validated with customer data or you will need to create a test plan to validate. Make sure it’s clear to them that you’ll be prioritizing features based on the impact to the customer and business as well as the build effort required.
In addition to stakeholder meetings you also need to get clear on what you have the power to influence in your role. For example, let’s say that your product is a website and one of the items that a stakeholder brings impacts not only the website but also requires iOS and Android app changes. If this is the case then it’s not up to you to unilaterally prioritize the feature. Initiatives with cross-product impact need to be prioritized in separate conversations with full product leadership support, as the scope is outside of what the individual product manager controls. Make sure you don’t accidentally commit to large features like this to your stakeholder because they will be upset if you initially commit then back out later.
Step 2: Rough prioritization
The objective in this step is to take all the needs from your various stakeholders, the data and problem statements, and turn that into a prioritized list. There will likely be some features that do not meet the definition of ready. Some of the items may not be well defined, or they may impact too many other teams, or there is open data questions, etc. This is the best way to do an initial cut to get to the working list of features.
In this step, you’ll also want to check in with your product leadership to get initial thoughts on how you’re approaching the prioritization to get feedback. It may be the case that certain initiatives are “must-do” because of senior leadership support. There may also be other background they can provide on certain features that will help you in subsequent steps, like additional people to talk to, or technical limitations to work out. Make sure to touch base with them before leaving this step to make sure you have all the information you need before moving to the next step.
Step 3: Product Vision
We have other posts about building your product vision (read more about creating a product vision board here), so I won’t cover in much detail here. What I will say is that the product vision is often forgotten but it’s incredibly important. It’s all well and good to have a backlog and to dive into building, but having a clear and coherent product vision that describes your product purpose, the objectives and strategies for the year is so important to yourself and your team I urge you not to skip this step. Do it, and thank me later!
Step 4: Talk to developers
As developers’ time is best spent developing, you’ll want to use their time wisely in this step. They are looking to you to help them prioritize the work that actually needs to be done and to protect them against what doesn’t. So help them out here by coming with a defined and coherent list of items that can be discussed to get some basic impact assessment.
Ask questions like this to get an understanding of impact for each item
- What back end systems might be impacted?
- What other teams, and how many, might we depend on?
- How much back end work is there?
- How much front end?
This conversation should be just that, a conversation. Get estimates that you expect to move, but don’t be afraid of communicating them. Your roadmap is a living document that is updated frequently. Don’t let perfect be the enemy of the good enough.
As an aside, this is the time when you should spend extra time making sure that your developers and working team understand the business need for each of these initiatives. No one likes looking at spreadsheets of requirements divorced from the business value and expected customer impact. Take this conversation as a two way street and solicit ideas and feedback on the overall product strategy and vision.
Step 4.5: Continuous inclusion of product driven initiatives
I’ve added this step here, but really this should be happening continuously outside of this flow. You, as the product manager, need to ensure that new work is created organically by discovering customer problems and turning them into solutions that can be prioritized. This is the whole product funnel and prioritization process that we cover indepth in this site, starting with envisioning then moving towards defining and validating, then executing and learning. For more on leveraging this process, head to our best practices section and read up! 40%-60% of your backlog should eventually come organically from your own investigations into ways that your product can be enhanced. This can be tough, but it’s crucial and it separates a great product manager from a good product manager.
Step 5: Prioritize that bad boy!
Let’s take a quick step back and review what you should have at this point in the process. You have a full and single backlog that is all encompassing of the work that your stakeholders want and expect of you in the next 6-12 months. You’ve had an initial conversation with your manager to loosely prioritize away to get you a realistic working list. Developers have been involved to give you a t-shirt sizing of the work involved in each initiative. You have a vision that your map will be driving towards. You’re ready to start putting this thing together!
There’s no secret sauce to prioritization. This is your opportunity to be you, and prioritize how you see fit. This is what the success of your product will rely on, and your success as a product manager will be determined. It’s likely that when you are new more of your backlog will be made up of features that have been added by stakeholders and others rather than you and your team. As you get to expert status more and more of your initiatives will be self identified and driven. You’ll know that some piece of the site is broken or can be improved to add sales, quantify the impact of fixing it, and get it into the backlog and get it done.
Questions to help prioritize
- What is the relative priority of the requirement based on stakeholder and leadership support?
- What are the dependencies for that requirement on other teams or other back end enhancements?
- What set of requirements should be grouped together into common themes and launched simultaneously?
- What is the overall business value of the requirement?
- What is the overall customer impact of the requirement?
Pro tip: when you get to the point of determining specific time required for each initiative – it should be based on your team’s velocity and a high level view of the work involved. For example, if you know your team can complete 50 points per sprint, try to get to a t shirt sizing in terms of points. Based on an estimate of 500 points for your list of initiatives you know that it will take your team roughly 10 sprints to complete all the work.
For more on prioritization, which is an art in itself, check out this article by Martin Eriksson.
Step 6: Build the product roadmap
The roadmap document should include several things. It should start with the product vision describing the overall purpose and value of the product. For example, if you own a website the purpose might be to drive sales, or sign-ups, or to educate readers. Whatever your purpose, clearly define it here and make sure that the rest of your document flows from this foundation.
Next, define the current state of your product and the point of arrival vision. Define the case for change. What’s working well right now and what isn’t? List the facts, usage data and customer research should go here. The rest of your document will focus on taking your product from the current state (things that aren’t working well) to the point of arrival state (where it’s been fixed).
Once you have the high level stuff defined, show the prioritized backlog. Do it as visually as possible and with as much data support and specifics as you can. Show the work that you have done and how you’ve brought it all together into a coherent roadmap showing what will launch when. Leadership will be looking for a very clear plan for how you are going from the current state to the point of arrival state, so make sure that your themes and initiatives illustrate that clearly.
A high level example of how you can visualize your product roadmap
Step 7: Get buy-in
Once the product roadmap document is ready, you’ll need to get your stakeholders’ bought into the strategy and approach. This can feel a bit like a roadshow sales pitch, but ultimately it’s critical to get this signoff before work starts so that everyone, and I mean everyone, with a vested interest in your product is aligned to the strategy. These meetings can get tough, so meet with product leadership first and make sure that they have your back.
Step 8: Start moving!
Once you’ve got your initial buy-in you will go back to your working team and discuss the fully defined vision and roadmap. Remember, this is the first time they will have seen it in some time so walk them through it from start to finish. Ideally, you’ve been keeping them updated in shifts at a high level in your standups and other team ceremonies. If not, then try to do that in the future. Pro Tip: the more communication the better. It’s a core value of the product manager job to your developers, and it’s a way to build respect.
Once you have the above steps done you’re ready to move to execution. However, as I mentioned at the beginning of this article the product roadmap is a living document. As shifts occur (timing, backlog items, priority), and they will, make sure to capture them in your product roadmap. And, you should also use your product roadmap to push back on changes whenever necessary. For example, if you’re asked to prioritize an enhancement that does not fall in line with your vision and there isn’t good data you should absolutely push back and say that while that feature is great and seems important it doesn’t fall in line with the prioritized product vision and enhancements already in flight, so at this time it will not be added. The vision is a guiding light that points you to that future state. Your job is to stay true to that.
Lastly, while you will be moving towards execution mode and tracking work to be completed, you can’t lose sight on step 4.5. You absolutely need to keep building your backlog and looking for new opportunities to improve your product and delight customers. You may find new items that knock off others that are in your backlog. That’s a good thing and you want to make sure that you and the team stay flexible to complete whatever work will have the biggest impact to the business and your customers.
Well that’s it! I hope it’s been helpful! Have some thoughts on roadmapping yourself? Drop us a note and become a contributor! www.productmanager.com/contribute
Purpose: Think of your roadmap as a strategic communication document. Its purpose is to show your team and other stakeholders what your product vision is and what the high-level initiatives will be to get there. It’s not a device for showing off every last nook and cranny of your development plan, and doesn’t need to include your list of specific bugs or minor features you want to get out the door.
Roadmap purpose: categorize, prioritize, determine timing for release
How granular does it go? themes vs. features
Group features/requirements based on how customers use the product, or in some other way
Scoring the effort (dev team) and customer impact (PO and stakeholder group)
Relative score is ranked to provide overall priority
Questions to help prioritize
- what is the relative priority of the requirement
- What are the dependencies for that requirement?
- What set of requirements belong together?
- What is the overall business value of the requirement?
- What is the overall customer impact of the requirement?
Determining time frame – should be based on your team’s velocity and a high level view of the work involved. Based on this you can divide the overall points expected for each high level feature by your team’s velocity and the resulting number is your rough number of sprints to build, providing you a rough length of time for each feature
[Add pic of the estimates are estimates don’t beat up your developers]
roadmap = features to be delivered / time that they can be delivered