Whether you’re a Jr. Product Manager at a startup, or an experienced Director of Product at an enterprise, there are certain best practices that apply across the board.
And what’s the best place to learn about these best practices? Straight from the minds of experienced PMs who’ve seen it all and picked up a thing or two along the way.
Here’s what 5 product managers learned about building better product roadmaps.
1. The product roadmap should be deeply connected to the product vision
The product vision is more than just the vision statement. It includes the product strategy, how success will be measured (metrics, KPIs) and the product mission. And like the product roadmap, all of these things communicate how a company plans to achieve the future they envisioned for the product.
When you connect the high-level product vision to the product roadmap, everyone in the organization understands their work better. They can make more autonomous decisions around their tasks so they align directly with the strategic direction of the product.
It can be easy to respond to what Cassidy Fein, PM @ echo360, refers to as “short-term fires” and sacrifice the long-term vision in the process. She says:
For Jr. PMs especially it’s really hard to say no to feature requests or keep the broader vision of the product in mind. You can get really bogged down by the details of a specific feature set. As you become more senior, your scope widens, the aperture of what you do and manage force you to widen your view and your day to day and the features you work on every day.
So it’s important to be rigorous about following the product vision religiously, then breaking it down in a way that clearly shows a connection with the initiatives planned over a period of time.
Patrick Carmitchel, VP of product management at TSIA, puts it like this:
It’s great to start by breaking your vision down into the people, processes and technologies you’ll need to achieve it over time. Vision is powerful but it will cripple you without the right modelling, positioning, and initiative planning required to solve the right problems first.
Patrick believes product managers can do a few things to close the chasm between that high level vision and the roadmap:
I suggest using a product management framework and/or software to bridge the gap between vision and roadmap. Your vision should be broken down into the business modelling components that are required to prioritize feature development based on the impact it will have on the experience and business. Personas, competitive analysis, SWOT, positioning, differentiation—these are the fundamentals that impact the roadmap.
Ready to start building better roadmaps? Check out our in-depth guide here.
2. Communicate your prioritization process for the product roadmap clearly
Prioritizing roadmapping decisions is hard. It’s hard to quantify impact, estimate accurately, and ensure that you’re focusing on the right data points and research to inform and justify the value of a decision. No one can predict the future, and so the prioritization process comes with some hard-to-answer questions like:
- What initiatives are worth the team’s time and effort?
- Will these initiatives put us closer to achieving our product, business, and organizational goals?
The answers aren’t so straightforward. Answering them correctly requires a mix of quantitative/qualitative research, PM instinct and experience, as well as a deep understanding of stakeholder and user needs.
- Is there an activity we can do to quantify the impact, effort, value and cost that this initiative will take?
PMs can use a prioritization framework at this stage. These methods help product teams evaluate, estimate and organize initiatives to ensure they will deliver the most value and impact for the business and the users.
- How can I ensure my entire organization understands the process behind prioritizing initiatives over others?
Prioritize your team’s understanding of the product vision above all else. This way, everyone will gain a sense of purpose and motivation to rally around a common goal. It also helps inform everyone about why certain initiatives are being prioritized over others.
Regarding that last point, Watson Mulkey, Product Manager at Simplifya, says:
Stop making the methodology of the roadmap a mystery. While it can be kind of fun to think about product prioritization as a sort of alchemy, shrouding your process for putting things where they are can create even more discontent around what's getting prioritized.
Cassidy Fein also believes in the importance of setting priorities in a way that includes everyone who might be invested in what’s being released.
Sales, for example, will want to know why things are being prioritized over others, especially if they have their own requests from customers they feel are valid and potentially more important than what’s being prioritized. Providing transparency is an important component of the PM role, after all.
Cassidy believes in establishing a process of transparency and constant discussion to establish that clarity:
We have an internal product roadmap and also one that we share with customers to offer that transparency. On the internal roadmap, we’ll work with our sales team in monthly sales reviews. We’ll go through what we released and we’ll compare it to our competition and our current market. Here’s what we have coming down the pipeline and here’s what we’re working on right now. The PM is the one thinking about that big picture, so it’s his or her responsibility to remind people why we’re doing all this. Otherwise, it can be really demotivating.
Start building beautiful + collaborative roadmaps with Roadmunk. Signup for a free trial here.
3. Remember who’s seeing your product roadmap
Each stakeholder group is different, so why would you show them the same product roadmap? You should explain to each department how the initiatives on the roadmap will bring the product closer to meeting the business goals and the overall strategy and vision. Some stakeholders will care more about scalability and performance than others, for example.
Jim Bodor, Managing Director, Digital Product Strategy at HBR, also believes that knowing your audience can make or break the success of a product roadmap as a communication document.
A roadmap serves many audiences. A lot of Product Directors/VPs/managers start with the idea that they will use a roadmap to track the work they and their teams are doing. Once that roadmap comes to life, though, and is shared more broadly, you start to realize that it’s actually more important as a way to communicate effort and priorities across a whole organization—and in many different directions. It must be shared in context, a positioned properly with each team. A group of PMs look at it very differently than a group of salespeople or an executive team will. Always remember your audience.
He explains how product managers can overcome this challenge:
Start to learn to add multiple layers to your roadmap, identifying which projects are absolutely certain, which are merely proposed or in a research phase, etc. Also, add tags and different views so a roadmap can be sliced in different ways for different audiences. You might show a sales team “projects with the highest revenue impact.” You might show an editorial team “projects with the greatest potential audience impact."
4. Align the product roadmap with the problems you’re trying to solve
If your product strategy isn’t in touch with the needs and problems of your users, then you need to take a step back and re-evaluate a few things.
The sweet spot of any product’s direction comes when you align the company’s business metrics with those user need metrics.
Peter Yang, Staff Product Manager @ Credit Karma, believes in nurturing and strengthening that business metrics-user problem connection above everything else when it’s time to decide what goes on the roadmap.
The first step is to get aligned on a problem you are trying to solve. You have to prove that there is a real customer need for any given initiative and how addressing this need will actually help the company grow its metrics. If you go talk about the roadmap before you align with the managing team and the engineers and the designer, some people will say: "This is just a bunch of features. What is the actual impact of what we are trying to do here?"
Here's the approach he suggests product teams subscribe to instead:
I think it is very easy to just jump straight to a solution and not land on a problem first. I think another benefit of landing on a problem first is that if your solution changes—or if you find out that there's a better solution to solve a problem—your team is less likely to turn on that solution. Because your team is more invested in the initial problem anyway.
A problem you are trying to solve, most likely, is unlikely to change. Even if the "solution" you launched fails, you're still kind of motivated to solve the customer problem in a way.”
5. Keep the product roadmap updated
Product roadmaps aren’t supposed to be static documents. They’re living documents that respond to change—and this change can come in many forms.
As the product, the industry, and the business ecosystem evolve, so do the priorities of the product team. The roadmap, a communication tool that reflects strategy and priorities, should also reflect these changes as they come.
Jim Bodor puts it this way:
At some point, a new product leader has to learn that maintaining and socializing the overall roadmap is one of the most important things we can do. That means, for one, keep it current at all times. It’s easy to fall into a habit of updating it once and forgetting about it for four weeks. That’s dangerous, especially if it’s publicly shared within a company. I now check and update my roadmap at least once a week, and sometimes as often as daily when we’re particularly active in shifting projects around.
6. Quantifying the qualitative for the product roadmap
Qualitative data is hard to synthesize and turn into an actionable initiative for the roadmap. But it’s not impossible, and the rewards of using feedback to inform the product roadmap are worth the effort.
By showing stakeholders where the need for certain roadmap initiatives comes from, e.g. in the form of user feedback, product managers can offer an added line of content for why it makes sense to work on those things.
Cassidy Fein puts it like this:
We’ve become more regimented about collecting feedback. Keeping a record of the things that are most requested, things that have gone stale and are not relevant anymore, we have a more formalized process for feedback and that has definitely helped with roadmapping and prioritization. Roadmapping is a visualization of priority, so being able to quantify these qualitative things like suggestions is important in order to be able to see what features make sense to work on.
Check out our libray of 35+ roadmap templates. Access them for free by signing up for a Roadmunk trial.