Last week, we held a full-day face-to-face roadmap workshop in the CPO Bootcamp. It was amazing to see everyone in person, interact, and learn from each other. As opposed to online workshops, in a live one, you can work directly with the participants on their roadmap and actually “knead the dough”, not just look at the recipe. We could do the work and reap the benefits, not just talk about it.
One thing I noticed is that people rarely let themselves go through an entire thought process since they tend to go straight to the bottom line. This is true in many aspects of the product leader’s work, but it is especially true when they plan their roadmaps. Usually, they list the items they need to accomplish in the upcoming year, but this isn’t what a roadmap is about. It’s not just the list of things we need to do. The roadmap is not a work plan, and the list of actionable items is – while a part of the roadmap – not the essence of it.
The most essential thing in the roadmap is the strategic background story, and that’s where most of your effort should be invested. It starts from the product strategy and eventually needs to explain these two fundamental issues:
- Why you want to do the things on your list.
- Out of all the possible roadmaps, why the chosen one was the best.
The list of items you want the team to work on during the upcoming year is only there to complete the story. You can use it as an example to bring the background story down to earth and make it more tangible. But the list of items itself will surely change, and since we want the roadmap to be a useful tool that is used regularly and does not expire quickly, it needs to include much more stable components than features and dates.
To get there, here are the things you need to consider.
Creating the Right Roadmap Is a Journey
I find it funny that we all know the roadmap is coming, usually on Q4, and it somehow always comes as a surprise. It is hard to find the time to do it between the rest of our duties, and working on something before you absolutely must do it, is very hard – especially with everything else you have on your plate, I know. But the consequence is that we tend to start too late, get caught unprepared, and finish it at the last minute.
One of the reasons lies in the approach people often take towards roadmap building: they try to engineer it while they actually need to create it. If you think that building the roadmap is a matter of organizing and prioritizing a list of items you mostly already know about, it is easy to see why postponing it to the last minute makes sense. But everyone knows that creation is a much less predictable process. It is very hard to do it under pressure. No wonder many musicians, writers, and other artists need to detach themselves from day-to-day life to be able to create their masterpieces. You should remember that roadmaps are also creations, and starting at the last moment can kill your creativity. Give yourself some time for trial and error, so that you can create a roadmap that you are proud of.
To get there, you need to think of yourself as a creator, not a planner. Allow yourself to ponder, and get into the mindset of an artist.
Imagine a painter, just before they declare their painting done. They are always looking at their creation, wondering if the feeling they wanted to evoke in the viewer is actually reflected in the final creation. Does the message they wanted to convey come forth? Is the painting beautiful? Is it complete?
Much like a painter, you need to allow yourself to take a step back and ask the same questions about the roadmap you created before you declare it done. Another thing to take from the painter’s mindset is to allow yourself to explore. Many great paintings took quite a few attempts to get right and become the masterpieces they eventually became. In older classic paintings, new technologies sometimes reveal an entirely different painting under the one that became famous. Putting their name on the painting, painters would never allow a painting to see the daylight if they felt it doesn’t accurately reflect what they wanted to say to the world – no matter how many attempts it would take. I encourage you to get into the creator’s mindset and iterate the roadmap until you feel it is a great one and accurately reflects what you want to tell the company about our plans ahead.
Back to the timeline question, you need some time to forget your constraints and truly explore what you want to have on the canvas. That also allows you to fine-tune your work, find the errors and gaps you had on the way, and do your job well. This exploration process might result in changes to your strategy, and will most likely have a dramatic impact on the list of items you originally wanted to include.
Approaching the roadmap this way is what allows the magic to happen. One of my favorite quotes is from former US President Dwight D. Eisenhower, during WWII, who famously said: “In preparing for battle, I have always found that plans are useless, but planning is indispensable.” The whole point is the revelations that come as part of the planning process, not the plan itself. It will probably change a million times over, so that’s not what you want to lean on.
The Roadmap Is Not a Work Plan
Many of my consulting customers tell me they have their roadmap for the next quarter planned, and I tell them it usually means that it is not a roadmap (with the exception of very young startups who genuinely don’t know where they will be in a few months). What most people call a roadmap is actually simply a work plan.
Mixing those two up is one of the most fundamental mistakes many companies make. While a work plan is important for keeping the operational pace of the company, the roadmap serves an entirely different purpose. A real roadmap serves as a strategic and organizational compass. If you encounter a stone along your trail, the roadmap is there to guide you on how to bypass it without losing your way.
Your roadmap can be an excellent communication and alignment tool, not only between the product and the development teams but also between the entire company management. Once fully aligned, they will be able to lead their individual departments in the same direction. If avoided, even with the best intentions, not everyone will know what the right path is. Consequently, everyone may approach things from a different angle, causing them not to connect and preventing any meaningful results.
That doesn’t mean you should not include items from your work plan in your roadmap, but they should be there to serve a different purpose. They are here to provide examples of what we mean in the background story of the roadmap and to help your stakeholders understand what you mean and make it more tangible for both you and them.
Roadmap Status Shouldn’t Be Delivered From Your Work Systems
Once you agree on what the roadmap is, you will need to update your stakeholders regularly on its status so that they know what to expect and when. But you should tell them where you are along the journey, not how many steps you have completed. It should only convey if you are on the right track, which is not the same as how many tasks were completed in the development.
That’s why sharing your roadmap with stakeholders directly from your work tools (like Monday or Jira and even others that are theoretically more product-focused) is not the right way. It would be like going to a clothing store and asking the salesperson for a different size shirt, but instead of giving you the right size, they tell you to look for it in the warehouse. It could work, but it’s definitely not what you really needed.
Much like you in that warehouse, the stakeholders will have difficulty understanding what they need by seeing your work tools. It’s not only because they are not familiar with these tools or work with them daily like you do. It’s also because what they really need isn’t necessarily there: they don’t have to receive the exact percentage of how much of the development has been completed. They typically need to understand the progress at a different level.
Moreover, when you give them access to your work tools, you lose the ability to use judgment over what you may or may not want to communicate outside.
For example, if you share everything about the product compilation, you can’t include the estimate you feel comfortable committing to. They will either get unstable deadlines that frequently change due to delays and unexpected challenges in development or might miss on additional areas that need to be completed on top of development before the product is actually ready (like documentation, marketing materials, etc.). As a product leader, you need to leave room for your own judgment when communicating the roadmap, or otherwise, why are you needed at all?
Instead of using a tool to share the status of the roadmap, use a simple email, a dedicated Slack channel, or a slide deck. Remember that you don’t need to include every little detail. They only need to get the bigger picture.
Communicating the roadmap status, much like the creation of the roadmap itself, is a creative process. You have a message to convey, even if it’s the details that tell the story. Make sure you fully own it, for the benefit of both you and your stakeholders.
