Beyond the Book: Navigating the Real-World Challenges of Managing a Product Roadmap
“The value is in what gets used, not what gets built”. — Kris Gale
As a wise man once said, no roadmap survives contact with reality.
Fires sparked to life left and right, yet there were no firefighters in sight, and I had no tools to fight them. Every hour, a new fire seemed to materialize from an unknown direction with no warning. I was on a path, a journey, to a new and wonderful destination. But I wouldn’t get there with the world burning down around me.
Thankfully, this is a metaphor. Fortunately, I have never lived through a fire of this magnitude in real life, although I lived through a minor one when I was a kid.
Yet this is what the life of a product manager often feels like.
Part of a fire brigade fighting a near indefinite set of fires, spawning randomly, without notice, and from every direction. Fires started by the most sophisticated arsonists — stakeholders. Firefighting while staying on course on the strategy and commitments of the roadmap is difficult.
Like a forest never cleaned, filled with leaves, debris, and branches catches fire quickly, managing a roadmap left to rot is challenging.
Forests without maintenance (natural or human) face a higher risk of fire. Similarly, a rotting roadmap without periodic cleaning faces a higher risk of falling victim to pesky, distracting stakeholder fires.
How does the rotting start? And why does it turn your roadmap into a burning forest?
Most self-proclaimed product gurus tell you things you already know — keep it up to date, anchor in the vision, and don’t overpromise.
All important, but not things that help when constantly fighting fires while feeling pressure to evolve your roadmap at the speed of light.
The struggle is real.
Thankfully, we aren’t going to talk about what you already know.
Instead, we will discuss what I’ve learned about applying best practices and managing roadmaps in the real world.
These techniques allow you to adapt to the environment, clear the rot, avoid fires, and pivot when needed while applying the proper maintenance to your roadmap.
Recipes (err best practices) are lab creations
Best practices are like recipes for a five-star dish — based on the ideal ingredients, kitchen, staff, and trained chef. These conditions only exist in the ‘lab’ where the recipe is developed.
To cook the recipe at your real-life restaurant, you must adapt it.
The same is true for roadmaps.
The best practice for managing product roadmaps is the same as the ‘lab’ created recipe for the five-star dish. Real life and the academic lab are different places.
The bottom line is that best practices need to be localized.
Baking the ideal product roadmap through localization
Let’s apply our metaphor of the recipe, cook, and dish.
The roadmap recipe, the best practices, and guidelines for roadmap creation are time-tested methods for preparing a delicious dish — the roadmap in a lab.
Chefs quickly move past the ideal and beyond their kitchen, as localization also requires steps to meet specific customer preferences, allergies, and more.
Local adaptation is why McDonald’s is often different in each country. The core of the McDonald’s experience is there, but the food and menu must meet local preferences.
The same holds for your roadmap — the best practices and guidelines must fit the internal AND external environment. Your product, team, resources, constraints, market, customers, competition, and many other dimensions vary.
Even once localized, and only once the cooking starts, the chef adjusts — for example, equipment might be dirty, malfunctioning, or missing.
In the same way, after you publish your roadmap, products might face budget cuts, shifting deadlines, new competitors, shifting customer demands, or any number of challenges.
The most important takeaway? Like a recipe cooked in a local restaurant for a local customer, your roadmap must reflect the localization of best practices to the environment and real-time adaptation to feedback.
Never strictly follow the recipe to create your roadmap.
Managing roadmaps once they are shared
Once created, an accepted best practice for roadmaps is to have a public version to set customer expectations and get feedback. Even this varies company by company.
Let’s look at a few for reference.
- SPARK: SPARK is a business lending solution emphasizing clarity in its product roadmap. SPARK maintains an ‘Under Consideration’ section on its public product roadmap page, allowing users to vote on suggested features.
- Zeaeye: A maritime safety company, Zeaeye, offers its public roadmap in multiple languages, using creative emojis to highlight important updates. This approach caters to a diverse user base and makes the roadmap more accessible and engaging.
- Buffer: Known for its social media toolkit services, Buffer demonstrates its commitment to transparency with a public roadmap that allows users to view ongoing conversations around each feature.
- New Relic: A cloud-based software for tech service performance monitoring, New Relic elevates its public product roadmap by hosting live events where it presents updates.
- Shopify API: Shopify’s API solution offers a creative approach to presenting its product roadmap in an article-like format, ensuring readers understand each change’s context and rationale.
Five companies, five ways of managing their public roadmap while following a best practice — seeking customer feedback. Localization at its finest.
Applying my favorite best practice :)
I couldn’t pass up the opportunity to share how I apply one of my favorite roadmap best practices — DELETE, DELETE, DELETE. If you want to learn more about this best practice, here is a link to the post where I covered it — ***Successful Roadmaps Avoid One Thing: Drift
But in summary — “DELETE, DELETE, DELETE. Be ruthless. Clear out the old. If it’s never going to happen or has unclear value, archive it. Dead features are often left. Doing this is the same as letting a vine grow on your wall and never pruning it. It will have dead spots. It will overtake the wall. It will grow in unproductive directions.”
Let’s go back to my favorite hypothetical multi-location donut empire — if you are a frequent reader, you will be familiar :) If you do not, here’s the scenario.
The board asked you to grow revenue by $100 million.
But this $100 million must come from Gen Z. So you’ve got to convince a generally health generation who avoids donuts to part with their limited funds in exchange for a donut — a trade I would happily make.
You plan to pair delicious physical donuts with a digital representation of the donut in the form of a unique NFT.
To accomplish this, you’ve created a product roadmap to kick off the development of the NFT, the associated marketplace to trade them, the in-store capabilities required, and the infrastructure.
However, fires abound when the roadmap meets reality, and the roadmap gets cluttered, drifts, and starts rotting.
You then remember that you must DELETE, DELETE, DELETE.
The idea is simple: clear the dead features from the roadmap.
Prune it.
Prune the product.
Yet, as you get out of the shears, you wonder if you should delete the dead features.
You are entering a new space with a new product, facing a new generation.
Instead, you decide to hide the features on your roadmap.
While you are ready to delete them, it’s best to keep them ready if you need to make a rapid pivot and they become viable.
This adaption of a best practice is a perfect example of how you can apply the idea of DELETE, DELETE, DELETE against a new roadmap for a new product in a new scenario.
In a mature product, you might apply this principle differently — for example, permanently clearing dead features or deleting existing features in a product and archiving the feature from the complete section of the roadmap.
Different scenarios warrant different applications of best practices for managing your product roadmap.
FAQ about roadmap management in the real world
While I’m not ancient, I’ve launched products at several companies. Yet, no matter the product, the market, or the best practice, I’ve repeatedly heard a few questions about applying best practices.
Question #1: How should I handle unexpected changes or shifts requested in the product roadmap?
The best practice is to put them in the backlog, conduct discovery, identify the value, and then prioritize and place them on the roadmap. And this is generally true.
You should follow these steps.
However, there are situations where you need to manage your roadmap through a life-or-death change.
For example, a new regulatory requirement that threatens to shut your product down as an example.
Following best practices is still important, but it might need to be faster. As a result, the change might fail to make your roadmap in time.
So, instead, in this case, you part from best practices and slot them on the roadmap to ensure your product will comply with the new regulation.
Then, you work backward. You add it before you know the results of discovery.
So, to answer the question directly, always follow best practices, take the time to understand the change, and then add it — unless it’s a life or death situation.
Question #2: How often should a product roadmap be updated?
This question has no perfect answer, especially regarding best practices or how you manage your roadmap.
Two factors dictate how often you should update your roadmap. 1) Velocity — what is the rate of change of the product, and how often are changes released? 2) Drift — How fast is your roadmap drifting away from reality and, therefore, getting out of date?
The higher the velocity of release and the faster the rate of drift, the more often updates are required. For example, let’s assume you release once every four weeks, and your roadmap loses touch with reality on average every six weeks.
In this case, your minimum update schedule should be every two to three weeks. Why? As a rule of thumb, I take both numbers and divide by two to set the lower and upper bounds of the range.
Question #3: How can I incorporate stakeholder feedback into the roadmap?
The standard answer is to put the feedback in the backlog and take it through the discovery and prioritization process. However, that is a process answer and the right one, but it only does a little to calm anxious stakeholders.
If it relates to a specific feature, simultaneously add it to the backlog and add the request specific to the notes — this will make stakeholders feel heard and acknowledged.
The other trick I have used is to have a backlog, name it ‘feedback backlog,’ add stakeholder input, and put it closer to the discovery section on the Kanban. It’s a simple yet powerful way to keep yourself sane, keep stakeholders feeling heard, and give yourself time to run the request through intake and discovery.
Please drop any other questions in the comments; I’d be happy to answer.
Bringing It Home
As we close, picture yourself as a product manager in the middle of an overgrown, disorderly forest in the middle of a lightning storm — the forest is a metaphor for your roadmap, and fires are popping up everywhere.
These fires?
They’re stakeholders’ unexpected challenges and demands, each threatening to torch your plans. Just like a forest ranger, you’ve got to keep the underbrush — your roadmap — maintained or risk the fires getting out of control.
It’s about more than just having a plan; it’s about actively keeping it clear of debris, or in this case, outdated or irrelevant ideas that could distract and derail your progress.
To succeed, you need a plan for your forest and to adapt forest and fire management best practices to your situation. The same applies to your roadmap — you must adapt the golden rules, guidelines, and best practices to your environment and company.
Ultimately, the most important lesson is that managing your product roadmap isn’t about sticking rigidly to a set of rules. It’s about using those best practices as a starting point and then adapting them as you learn more about the needs of your product, team, and customers.
