Roadmap Change Frustration
Part 5 - Successful Roadmaps Series
Change is inevitable, and so are changes to roadmaps. But sometimes, the frustration of not seeing things go according to plan can be overwhelming. It's like being lost in a maze with no clear way out. Here are some observations on change frustration with product roadmaps.
Firstly, it's important to acknowledge that roadmaps must play in the world of progressive elaboration. Progressive Elaboration means the more your work with something the better you will be able to understand it and predict its future behavior. This leads to road maps looking like treasure maps that lead you to believe there's a pot of gold at the end of the rainbow, but in reality, you might only find a rusty old tin can. Progressive Elaboration is learning and adapting. It refers to the ongoing improvement of a roadmap or plan based on new learnings and insights obtained while executing the roadmap. When you first start up a roadmap you will know little about capabilities and objectives included on the roadmap. Over time changes to the roadmap will clarify and broaden your understanding of the roadmap’s components.
You can overcome this by setting expectations and defining the propose of the roadmap. Roadmaps are flexible and based on the information available at the time they were built. Progressive Elaboration forces change – sometimes small and sometimes large. Set expectations with your team about the need for learning and adapting as they progress forward and developing the vision. Be sure it’s understood the importance of flexibility. The road map isn’t laminated or carved into stone. Roadmaps are a living a breathing reflection of the path the team is taking toward completing the vision.
Secondly, change frustration with product roadmaps can feel like being stuck in traffic during rush hour. You're moving forward at a snail's pace, surrounded by honking horns and impatient drivers. Similarly, it can feel like your project is stuck in neutral while waiting for key milestones or approvals before moving forward.
You can overcome this by sharing your progress. Let’s say you have a roadmap with multiple releases. Each release has multiple capabilities embedded into that release. If you are showing progress only at the release level, it can seem like progress is very slow. Breaking the communication down to each capability in the release is an effective way to show progress. Set the expectation that capabilities can require multiple sprints to complete. It would seem logical to estimate capabilities at a high-level but research show those estimates are widely inaccurate. They are often referred to as Rough Order of Magnitude (ROM) estimates. The standish Groups research on estimates showed that ROM estimates are only accurate 20% of the time. Communicate what has been completed for the capability. Communicating what decisions were made about the capability and design helps to show progress.
Another approach is to break down capabilities into smaller sub-capabilities. Review complex and extensive capabilities. You are at the roadmap level, so this is kind of a gut feel. Ask your team about which capabilities seems to be too large or extensive to manage effectively within a few sprints or weeks. You may not always find a way to break it down, but it’s good to ask the question. When broken into smaller pieces it’s easier to show progress and easier for the team to work on the overall capability.
Thirdly, product roadmaps can also be compared to cooking recipes. You follow all the instructions step-by-step, but when it's time to taste the dish, something just doesn't quite hit the mark. It can be frustrating when you've invested time and resources into developing a product that doesn't quite meet expectations.
You can overcome this by setting expectations around a capability's feasibility. Not all capabilities can be developed. A capability may be unable to be developed due to an architecture, technology, or regulatory compliance issue. Capabilities that can not be completed may need to go back to the starting point and the vision. Re-crafting a capability seems like a step backward but your team has learned valuable lessons.
Lastly, change frustration with product roadmaps is like playing a game of Jenga. You carefully stack each block on top of one another until suddenly one wrong move sends everything crashing down. Similarly, one small hiccup in the development process can have a domino effect and derail your entire roadmap. It can take a lot of energy and effort to pull the team back together when things fall apart. Progressive Elaboration ensures that are some point you will hit a roadblock and things will fall apart. The important part is having the discussion on how to move forward, adjust the vision if needed, and align the capabilities. To overcome this obstacle, you will need to reaffirm the vision as it may have changed. Once the vision is reaffirmed then realign the capabilities to the vision. Do the capability still makes sense? Are they help fulfill the vision?
To wrap it up,, change frustration with product roadmaps is an unavoidable part of any development process. It’s tempting to change the vision to make it easier, but that might not be the right approach. Consider changing the roadmap first before attempting to change the vision. With humor and perspective on the roadmaps ups and downs will help alleviate some of that frustration along the way. Remember: keep calm and carry on building!