Some people hate roadmaps. They are a pain to put together, formatting is annoying, your plans will probably change next quarter, and who looks at these things anyway? As Drift CEO David Cancel said of a typical roadmap, “either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.” While much of what Cancel says is true, because no roadmap is future-proof, I’d encourage any roadmap haters out there to think about it differently.
Your roadmap is more about the journey than the destination.
Many of us use roadmaps as one-way communication to stakeholders, but the real magic happens when you work collaboratively WITH your stakeholders. Start by listening to their needs and including them in the process. When you work together to define roadmap items, determine priorities, and evaluate trade-offs, you can use that process to build a positive, trusting relationship where your stakeholders can proactively say “yes” or “no” to their ideas. From there, instead of being adversaries, you can agree as a group to say no to a request.
The Five Steps to the Roadmap Journey
1. Align on Problems
The first step for any roadmap is to define the problems you’re trying to solve. Get your stakeholders involved in this process and listen to them. Ask questions to get to the root of stakeholder requests and, if possible, go out into the field and observe the problem directly to gain a deeper understanding of the context.
Next, work together with your stakeholders to help them understand the difference between a problem and a solution (hint: you can build a solution, but you can’t build a problem), and iterate on the problem statement(s) until you have a shared understanding of what you’re trying to solve.
Say someone comes to you and proposes creating a car to replace horse travel. A car is a good idea, but it depends on what problem you’re trying to solve. If you’re trying to get one person from point A to point B faster, maybe a motorcycle is the right solution. If you want to get a lot of people from point A to point B, perhaps you build a train. If you want the cheapest transport possible without walking, maybe it’s a bicycle.
2. Define Roadmap Items
Once you define the problems, break them down into specific items that will go in your roadmap. Keep in mind that these roadmap items are still problems, not solutions. But they are smaller chunks of the issue that you can solve incrementally. Problems can be broken down into roadmap items in several different ways, such as themes (logical groups of items) or phases (sequential groups of items). Each roadmap item should be expressed as an outcome and not a solution. This will enable the team to pivot the specific solution as new information becomes available.
Let’s look at a “Phases” example. I worked on a product to facilitate quality control inspection (QC) in the fulfillment centers. The existing process had two major limitations:
- Knowledge-only a few Supervisors knew about it.
- Precision-Supervisors could only remember categories, like couches, rather than the desired list of specific couches.
We were able to fix both of these problems in phases.
- Phase 1: Enable operations to create and manage a precise list of QC items. This was done by creating a bulk upload tool and a UI for supervisors to view the list.
- Phase 2: Ensure all Associates know which cartons to send to QC. This was achieved by adding this information to an existing manual sortation process.
- Phase 3: Allow Associates to record the QC results. We delivered by creating a mobile device workflow.
And now for a “Themes” example. I once worked on a task management product for nurses. After an in-depth discovery project, I aligned with my stakeholders, and we determined that the main themes were data entry, task prioritization, and communication with other nurses. When a stakeholder suggested adding a feature to explain the procedure to the patient, we pointed to the three focus themes. We then decided together that this new request would not be in scope right now because it did not fit into any of the previously agreed-on themes.
3. Determine Priorities
Once you agree on what items should go on the roadmap, you must determine what to work on first. Sometimes this can be difficult: we’ve all had stakeholders say that every single item is “Priority 1.” A good way to solve this is to list out all the roadmap items and work together with your stakeholders to rank them in order. Creating an ordered list forces tie-breaking conversations about which item should be prioritized above which other item and why.
This joint prioritization method can be especially helpful when you have multiple stakeholders that frequently disagree. Through these conversations, they learn more about each other’s points of view.
I once worked on a product that enabled electricity utility companies to run Demand Response programs, which essentially pay people and businesses to use less electricity during peak times to avoid blackouts. Because there are many different electricity utility companies in the US, and each operates slightly differently, my company assigned a program manager to each company. These program managers were my stakeholders, and they all had different priorities for the product.
So what did I do next? I got all of them in a room together, and we started looking at the list of problems we could solve. The conversation among the stakeholders was fascinating (they had never been in a room all together like this!), and through a mediated conversation and a ranking exercise, we ended up with a prioritized list of goals that we all agreed on.
4. Evaluate Trade-Offs
Once you have a prioritized list of problems to solve, you now have the difficult task of deciding how many you can start working on right now and what should be put off until later. If a prioritized list expresses the relative importance of each item, then the tradeoffs are those that will be tackled at a later date - tradeoffs fall “below the line.” This is the part of the process where you get to say “no,” because those items below the line are the ones you are not working on right now.
Working with your engineering partners is the key to figuring out where to draw that line. They can provide a very rough estimate for each of the roadmap items. This could be as basic as a number of person-quarters required to complete the item. And don’t forget to add a buffer based on the solution’s level of uncertainty - this could be 1.5x, 2x, or even 3x the estimate (You’ll thank me later on that one.).
You may be asking: “how do I explain the need to draw a line in the first place?” A famous project management diagram called the Iron Triangle illustrates the connection between scope, resources, and schedule. Essentially, it says that if you want to increase one of the three sides, you must decrease another. If you fail to do so, quality will suffer.
If the timeline you’ve laid out is not acceptable to your stakeholders, discuss which of the other pillars you want to shift. Maybe you can get more resources by hiring or by pausing a project in another part of the company. Perhaps you can deliver value faster by reducing the scope of the initial launch. In the car example above, the motor, steering, and seating may be released first, and the roof/weather protection can be done in phase two. The one thing you should make abundantly clear is that if you shorten the timeline and fail to adjust at least one of the other two pillars, the quality will suffer.
5. Maintain Alignment
Your roadmap should be a living document re-evaluated periodically with your stakeholders. Once your aligned roadmap is documented and widely shared, you can use it as a starting point to discuss future requests. When a new request comes in, it’s now easier to have a conversation about tradeoffs.
“Sure, we can add that feature, but what would you like us to take out of the plan to make room for it?” Sometimes the new request is both important and urgent, and pushing something out to accommodate it makes sense. At other times, just asking the question, “what should we take out” will result in the stakeholder saying “no” to themselves!
As you continue to iterate on your priority list over time, it’s possible that many of the tradeoff items will remain below the line…perhaps indefinitely. When you involve your stakeholders in creating an aligned roadmap, you have a basis for evaluating future requests. This can help you make ongoing decisions quicker and more rationally. Saying “no” can then become a good thing because it increases focus on the most important features and reduces distraction from the merely “nice to have.”
I leave you with one final point of emphasis—make a commitment to collaborate with your stakeholders and, instead of being adversaries, say no together. They might even thank you for saving them from making a bad decision!
