6 Things Product Managers Should Do Before Building a Roadmap
April 21, 2016

6 Things Product Managers Should Do Before Building a Roadmap

The product roadmap is one of the most essential documents your company creates. It shows what your product aims to achieve, how it will fulfill important goals, and how your product will impact the larger organization.

The product roadmap is essentially your ultimate guide to how your company will deliver new products and features. But if you have never built one before, how do you actually create your first product roadmap?

Product managers are often tasked with improving an existing roadmap — but sometimes they need to create one from scratch. And that begins with devoting time upfront to defining your strategy at the company and product levels.

This process will be challenging. But it does not have to be painful. And if it was easy, everyone would be a product manager. You can set your company and your product up for success by following some of these proven steps first:

Understand your company’s strategy There is a crucial — often ignored — first step before you start scoping new products and features for your team to build. You need to start by figuring out why you must come up with new products and features in the first place. What purpose will they serve? How will your business benefit from them? You can’t answer these questions without true understanding of what your company aims to achieve.

To do so, make sure that you understand the latest company strategy. And if you do not (or it is not clear) arrange a meeting with your boss (or anybody else on the management team who can articulate this for you). Make sure it is clear and you know where the business is headed.

It’s true that this can be a very long, broad conversation. So, focus on understanding this: if your company could only accomplish three things in the next 12-18 months, what would they be?

The answer shouldn’t be product-specific. Instead, you need to understand this answer on a higher, more strategic level. For instance, perhaps one of the company’s three goals is to have a certain number of users and revenue. Another goal might be for your company to graduate from small and mid-sized customers to enterprise-level customers.

If you’re a CEO in a very small company who is responsible for building out your product roadmap, then remember that strategy starts with you. If you’re unable to fully articulate your company’s strategy, it won’t matter how detailed or grand your product roadmap is. It won’t have any clear direction built within it.

Align your company strategy with your product strategy So, now you have a clear sense of the company strategy. This still isn’t time to start dreaming up new products. First, you must do more heavy lifting to set the proper foundation. And this is where your product strategy comes in.

Blog - 6 Things Product Managers Should Do Before Building a Roadmap - inline image

Some product managers find it most helpful to define their product strategies in one specific statement. I find it more constructive to come up with several prioritized “themes.” These overarching themes will serve as guardrails for you to focus your team’s development efforts. When someone proposes a new idea or questions how to prioritize features, these themes can guide you all to the right answers.

When building out your themes, remember that a theme is not a product in itself. It’s direction for why you will prioritize certain products and features over others.

In the past, I helped create a product roadmap for a company that produced fitness trackers. One example of one of our product themes was, “Inspire the 80 percent of inactive people.”

This theme was influenced by research which showed that 80 percent of our target market was mostly inactive and sedentary. Many fitness trackers — aka our product competitors — focused on features for the 20 percent of motivated, healthy, active people. We were more interested in serving this sedentary segment.

So, we strategically opted not to pack our devices with as many features as possible that we knew these users would not be interested in. Instead, we kept costs down and focused only on features that would not be so intimidating, yet would inspire users into action. This product theme helped us fulfill our product and company strategies in tandem.

Receive buy-in from your colleagues, stakeholders, and customers Once you’ve come up with your most critical product themes, it’s important to get feedback from stakeholders for your product. This includes your management team, employees, and even your customers. If your company is large, you can consider compiling a group that represents a cross-section of your overall business.

When you hold these sessions, ask everyone if these themes ring true to them. Try to pull out other themes that might be considered alongside or in lieu of what you’ve come up with. This exercise helps everyone in your company think more critically about your product’s relevance.

Customer conversations can be similar but should be held in 1:1 phone calls or meetings. Proper context should be set that this is not a sales call. Then, use these conversations to confirm if the themes you’ve developed actually solve your customers’ pain points.

Ask specific questions about their needs. Pull out the problems that they’re experiencing which your products are expected to resolve. If your themes aren’t matching these pains, this is your cue to step back and reassess your strategy.

Begin the ideation process Now that you have proper direction, it’s time to determine the major products and features for your team to develop. In some cases, you may not be starting from scratch. Start by reviewing your product backlog if you have one. You might be surprised to find plenty of ideas that align with the themes you’ve developed.

Next, you can conduct your product team’s own internal ideation session. No idea should be discounted at this stage – so long as it fits within your strategic themes. Continue with this process until you’re confident that your team has exhausted all ideas.

If the initial ideation session was conducted with your product team only, then go back to the cross-section of colleagues that you consulted earlier and run a similar session with them. Afterward, compare all ideas from both sessions and prioritize them under each theme based on their projected business impact.

At this stage, keep in mind that you should stay high-level with proposed products and major features. It is a good idea to make sure that members of your development team are included. That said, their expectation shouldn’t be that you will provide so much detail that you’ll be able to properly size products and features out.

Size out each idea At this stage, you have your major product themes as well as ideas for products and features within those themes. But you still don’t have perspective for how much time it will take to develop these products and features. That’s why it is now time to properly size each individual idea.

Before you block off the next several weeks of your and your developers’ calendars, know that you should not aim to size out every single piece of each product. Instead, look for high-level estimates of what it might take to develop these high-level products and features.

Sit down with your Chief Technology Officer (CTO) or engineering lead and have a working session to discuss high-level sizing based on each theme and product. Your goal is to get effort estimates that you can work with. Know that before you start your sprints throughout the year, you should be diving deeper to even more accurately size each piece. But for now, you want just enough information to make educational estimates.

Reassess and prioritize Approach this meeting with realistic expectations. It is possible that the above exercise results in five years of development time. That might initially depress you. But keep in mind that you only have to focus on what you believe will make the biggest impact. Those features that you thought were mission-critical before might not look so important if you see that they will tie up your development team’s time for the foreseeable future.

You will find that certain features are not going to be worth the effort it would take to develop them. Whatever the case may be, you can now use all of the information you have to prioritize within each theme.

Finally, you are ready to build a roadmap. You can do this using a tool like Aha! or in a simple document or spreadsheet if you’d like.

The important thing is that you have done the strategic legwork up front, gathered input from key stakeholders, and prioritized what matters most. Now, the results of your work are within a shareable document that you can send freely and update at any time.

One final piece of advice. Your roadmap will change – and that’s okay. Company strategy (especially at the startup stage) tends to pivot. So, revisit your roadmap often (at least monthly) to ensure that it still rings true. The great news is that your hardest work is done. Your product roadmap will help you set direction, articulate the future, and — most importantly — create the products and features that matter most for your business and customers.

This is a guest post by Mike Belsito. If you are looking to be a great product manager or owner, create brilliant strategy, and build visual product roadmaps — start a free trial of Aha!

Mike Belsito is a startup product and business developer who loves creating something from nothing. Mike is Co-Founder of Product Collective and Co-Organizer of Industry 2016, a summit for those who build, launch, and scale world-class products. Mike led tech companies such as eFuneral and Movable prior to their acquisitions.

Guest Author

Follow Aha!

Related articles

The Product Plan vs. the Release Plan
January 8, 2018
The Product Plan vs. the Release Plan

Confused about the differences between product plans and release plans? Learn how to use both product plans and release plans to deliver a winning product.

The 6 Principles of Strategic Product Roadmapping
April 14, 2020
The 6 Principles of Strategic Product Roadmapping

Strategy is not optional. I wrote this just a few weeks ago in a blog post about recent world events. The context was how to make clear decisions when the future is…

User Stories vs. Requirements: What Is the Difference?
January 23, 2018
User Stories vs. Requirements: What Is the Difference?

Are user stories and requirements the same, or do they serve different purposes? Find the answer (and others) in this guide.

Agile vs. Roadmaps
March 2, 2020
Agile vs. Roadmaps

Have you ever tried to follow a complicated recipe? Exotic ingredients, specialty cookware, and professional techniques — it takes more than instructions to cook a…