Roadmap Roadblocks — Common Obstacles in Building Product Roadmaps
A Roadmap is a foundational tool for developing a product. The Product Roadmap serves as a guiding document that aligns teams, stakeholders, and resources towards a common goal.
But the creation of this vital tool is not always straightforward. The path to creating a product roadmap is full of obstacles. In this article, we’ll explore some of the significant challenges that teams face in crafting an effective software product roadmap.
People Who Don’t Know What “Roadmap” Means
One of the most common Product Roadmap roadblocks is a lack of understanding of what a roadmap is supposed to represent.
The term “roadmap” on its own seems to conjure different expectations in the heads of various stakeholders. Your job as a product manager is to be very clear about what a roadmap IS and what it is NOT.
A product roadmap IS a representation of the priorities and vision of your team or company. A product roadmap is an accessible vision of work that has been shared with your teams to guide their efforts. When considering new work or changes to planned work the product roadmap can act as a north star indicating whether or not that change makes sense for the team and company.
A product roadmap is NOT your jira backlog of tasks.
A product roadmap is NOT a detailed breakdown of team resources and what each individual contributor will do each day complete with granular tasks.
A product roadmap is NOT a perfect minute-to-minute plan that has been etched in stone and is unchangeable.
A product roadmap is NOT a contract of what will be completed and when.
A product roadmap is NOT “the plan” but rather the foundation on which “the plan” is formed. A product roadmap serves as a framework for teams to build their work around.
Siloed Roadmapping
Building product roadmaps is a team sport. A product manager’s role is to invite many voices and skill sets into the process to get a clear and informed view of priorities and goals. I like to treat product roadmaps as just another product that needs to be built: which means taking in information and requirements from multiple sources to form a solution suited to your intended audience’s needs.
When product managers try to build a roadmap in a silo without diverse skill sets and voices they often end up with a final product that does not accurately represent the whole picture.
Now does this mean that the solution is to put the whole company in a room and have people talk over each other for hours on end? No. Design by committee rarely results in anything good. But what it does mean is that you need to have strong relationships with stakeholders and understand their priorities, as well as understanding where your product fits in the larger market.
Is there tech debt? (Likely)
Are there financial goals to consider? (What company doesn’t have them?!)
What feature requests are the sales team hearing? (More than you can count!)
What are you seeing from competitors that might influence your direction? (Many things!)
I would suggest that you take these various inputs, whittle the list down based on perceived value and priority and then form a rough first-draft roadmap. Don’t worry about getting it perfect at this stage — you’ll revise and rewrite it several times as you gather feedback from the team.
From here I usually spend time with smaller groups and teams socializing the draft-roadmap, gathering feedback and adjusting the draft-roadmap based on that feedback. I find conversations with smaller groups tend to be more fruitful for gathering useful, actionable feedback. Larger groups tend to just turn into competing interests talking over each other and some voices being ignored.
As you continue to iterate on the roadmap, bring more and more of the key decision makers together at the same time. Your ultimate goal should be to find a general consensus among leadership that the roadmap is a balance of interests informed by data.
Agonizing Over Roadmap Format
There are any number of SaaS products claiming to be the ultimate in roadmap representation. I’m not here to endorse any of them. (Though by writing this article social media will inevitably continue to serve me ads for product management tools…)
How you choose to represent your roadmap is up to you and should be decided by the needs of your team. Afterall, the Product Roadmap is a product you are building for your team — make sure it’s presented in a way that works for them.
I would suggest adhering to a few guidelines:
- The Roadmap is accessible to the team. If someone on your team wants to reference the roadmap they should know where to find it.
- The Roadmap represents the development goals AND their priority within a timeline. It’s not enough to just present a list of “What” you want to build — but your roadmap should give a brief explanation of “Why” you want to build something and “When” you think it needs to be done.
- The Roadmap states who the user can talk to in order to learn more. Don’t make your team hunt for additional information. Assign someone as the authority on each roadmap item.
Your roadmap can be done digitally or with sticky notes. The format matters less than what it provides: clear, articulate accessible information that states a vision and a development direction.
Roadmap Breakers
Every company has one: That person who thinks that the agreed upon roadmap doesn’t apply to them. They and they alone have a compelling reason to completely upend or ignore the agreed upon roadmap priorities. This is a roadmap breaker.
To build your roadmap, you found consensus regarding what your team should work on, why it is a priority and when it needs to be completed. But when people ignore these shared goals it not only threatens downstream efforts of those implementing, but it creates chaos within the group’s vision and gives space for others to go rogue as well.
Product Roadmaps are not created and then left alone on a pedestal. They are living documents to be referenced, evaluated and adjusted. When a team member comes to you with an idea that deviates from the roadmap it is product management’s role (with input from others) to determine if that deviation is warranted. You need a stated process that takes in these suggestions and gives a verdict. If you are going to create a roadmap as a team, you need to agree as a team to change it.
What you cannot allow to happen is for that teammate to become a roadmap breaker.
Now, in reality, this is easier said than done. I’ve worked at companies where the CEO and CTO are the roadmap breakers. Your job in product is to take information, present the outcomes of the change and recommend a course of action. You may be overruled, but you need to present your case and potential consequences.
Roadmap Clingers
The opposite of a roadmap breaker is the roadmap clinger. This person views the roadmap in almost sacred terms and seems to believe that the roadmap cannot be deviated from ever — regardless of new information.
And while changes to the roadmap should not be done frivolously, they do need to happen on occassion. Why? Because you learn new things. Because business conditions change. New technologies emerge. New regulations are passed affecting entire industries. Competitors pivot in unexpected ways and shift the market. As conditions change your roadmap should change, otherwise you’re utilizing a map for a different time and place.
The same process that you use to slow down your roadmap breaker is the same process you can use to unstick your roadmap clingers. Gather the data. Ask questions. And form consensus to find your answer. I’ll say it again: If you are going to create a roadmap as a team, you need to agree as a team to change it.
Conclusion
Making a roadmap is tough. It takes time, effort and a lot of consensus building. But here’s something that should cheer you up: It gets easier with time. The more iterations of this process that you go through the more second nature it will become. Practice doesn’t make perfect, but it does make progress.
