Claim Your
Product Coins
In my second job as a Product Manager, the VP of Product loved roadmaps. He requested a roadmap and slides for literary everything. He always said:
“Give me an exec-summary and one to three nice slides that I can share with the Management Team.”
On some days I felt more like a Slide Designer than a Product Manager. Nevertheless, during that time I learned a lot about prioritization and creating agile product development roadmaps. (+ Google Slides 🎨) Both of these things go hand in hand and are very important when it comes to making a good short-term plan.
In this article, I’ll take you through the step-by-step roadmap creation process which will cover:
Even if I’m focusing on a “product development” roadmap, you can apply most of the principles to almost every other type of roadmap.
I think the best way to explain that is in pictures. In my previous article about the elements of a product strategy I highlighted this quote:
“A goal without a plan is just a dream.”
That’s what I develop the product roadmap on:
Everything a Development Team works on is subject to a bigger goal. The bigger goal is called “the product vision” and the high-level plan to get there is the product strategy. The detailed plan is the product development roadmap.
A big mistake I made many times when kicking off my career was to simply “create a roadmap.” Over time I’ve learned and realized it’s way more than that. The roadmap creation process requires preparation, communication, and alignment. The result of that isn’t just a couple of slides that present the planned future. It contains answers to the following questions:
If a product vision and strategy are already in place you can reuse them for your product development roadmap. If not, these questions should be answered separately in the roadmap slides or a tool of your choice.
Abraham Lincoln once said:
“Give me six hours to chop down a tree and I’ll spend the first four sharpening the axe.”
I think that’s a great mindset many people should adapt to.
There are 4 crucial things a Product Manager needs to do to be able to create a great product development roadmap:
Number 1 is a prerequisite and is worth many separate articles. Numbers 2-4 are necessary in order to start the “real” work. I always initiate point 2 by talking to stakeholders.
I see the interaction part with stakeholders as the “axe sharpening” part of the quote. Knowing what the market needs doesn’t set the roadmap in stone. Stakeholders have their own needs, wishes, and requests. A Sales Team might want different features from those a Support Team would want. What’s most important, is to listen to people and gather the relevant information that impacts me and my team.
I recommend doing real deep dives when you talk to stakeholders and ask them what their needs are. There were many times I was just taking note of something they wanted without asking why and for more details. I’ve always found it helpful to invite an Engineer to conversations with technical stakeholders. Not only to better understand everybody’s needs but also to mutually exchange knowledge. Involving team members helps them to better grasp the bigger picture and to develop a sense of importance and urgency. In his book “Inspired”, Marty Cagan recommends always interviewing customers with a Product Manager, an Engineer, and a Designer. Involving at least one of them in stakeholder discussion won’t hurt too. I wrote a “How to identify and manage stakeholders” article where you can learn more on the topic.
The second and hardest part I’ve been faced with multiple times was that of prioritization. Obviously, I can’t fulfill all my wishes at once. Some of them never. That means, saying no is not only important, it’s also crucial.
Note: Please keep in mind that the preparation phase requires talking to your team. You can only gauge the bigger picture when you know what they plan to build technically (+ dependencies). And they only know what to plan for the future if they know what’s most important product-wise.
It’s not a chicken and egg problem. The product vision and strategy give everyone a clear direction in the first place.
The product development process covers many different steps and phases. The outcome (or sometimes just output) of it is always software in the form of a release of a
There are two more important things you need to be aware of. Does the release include broader customer communication (external) and/or training of different departments (internal)? In B2C that’s usually the case. In B2B, it can happen that you have certain (automated) release cycles and your customers want to test the software in e.g. a sandbox environment.
In order to know what type of roadmap I need to create, I start with what I call “pre-prioritization”. That means defining the first draft based on my best knowledge after doing market research, talking to stakeholders, and first conversations with my team. There are many ways and techniques out there to prioritize features such as:
It’s not easy to define what the best method is. I tried all of the listed ones and realized it depends on the amount of time and information I have in place. After I know how priorities roughly look, I start visualizing them in some slides or a tool.
Let’s take a look at two different examples:
Let’s imagine we’re about to launch an iPhone game. The roadmap would contain key features (technical and non-technical) that need to be developed to finish the MVP. All features are categorized in different milestones such as an alpha and beta testing phase.
On many occasions, I’ve come across Product Managers not visualizing work such as launch preparation, training (e.g. support, sales, etc.), and more. My recommendation is to always add that information as well. It helps to
In this example, we’re an eCommerce SaaS platform such as “Shopify.” We’ve decided to replace the existing product catalog service (the service that stores all product data such as name, prices, tax classes, images, and more). The goal of this service is to be more robust and to scale 10x more product data. This new service will affect the whole platform and, therefore, all of its customers.
In such a case, it’s important to have a clear migration plan starting with a batch of customers that have a small number of products and order volume. From there on more and more badges will be migrated to the new service. (simplified example)
Note: There are many ways to design a roadmap or migration. The goal of this article is to “visualize” the creation process of it.
After I’ve created the first draft with a couple of high-level dates it’s necessary to share it with my team. By then my roadmap contains information about the long-term goal, (business) goals, and the detailed roadmap. I share this document one day before the meeting happens so that the team can prepare. Depending on how much I’ve involved them beforehand, a meeting will go on for 30-60 minutes.
If my roadmap touches different domains and Engineering Teams, I suggest always syncing with the other Product Managers from the outset. We either pitch the roadmap individually in our team meetings or schedule a bigger session with all those involved.
The main topics I try to cover and gain clarity on are:
I wrote an article on how to make meetings and grooming more engaging if you’d like to dive deeper into the topic.
The alignment meeting usually entails adjustments and follow-ups. Therefore, it’s important to keep pushing and driving it as a Product Manager. I keep my team in the loop until we’re all on the same page.
After the priorities are clear and additional information has been added, it’s time to let the rest of the company know. At this stage, I would have already spoken to stakeholders so they will be interested in seeing the roadmap. I either share it via email or schedule a meeting(s), but this depends entirely on the size of your company. I personally rarely needed to adjust the roadmap again. This can sometimes occur though, and often for the following reasons
If you’d like to make sure that you cover all relevant stakeholders and departments I recommend reading this article which includes a product launch checklist.
The next big step for you and your team is to start building what’s on your roadmap. If you haven’t already filled up your backlog, it’s time to do that now. Here are some more useful links that can help you to better prepare your projects:
One important aspect we haven’t looked at is the timeframe of a roadmap. I believe every roadmap that is longer than 6-12 months (depending on your industry/business model) should be a product strategy. The likelihood that a roadmap longer than 12 months will stay the same and be achieved is in fast-changing times close to 0. The Agile manifesto describes this very well:
“Responding to change over following a plan.”
Another related thing I’ve learned the hard way about roadmaps is:
The moment they’re created, they’re outdated!
Is that bad though? 🤔
No, it’s not! That’s the nature of it all. It’s, however, crucial to regularly review the plan and adjust it accordingly. A monthly revisit, whether the plan is still valid or not, will help you stay on track.
How agile do you create product development roadmaps? Let’s chat on Linkedin.
