Roadmaps have an internal contradiction. They set up a path for us to walk on, and the path always changes. If we stick with the Roadmap’s planned path and not walk on the actual path we lay, we’d end up at the wrong rabbit hole. Because on every step we listen to every Feedback given after a Change, the path changes while we walk on it. We Deviate from the original planned path. And the ever changing path is the one we should walk on, in order to get to where we are supposed to be.
Once there is a Roadmap, Deviations from it are necessary in order to fulfill the Roadmap’s actual goal. If we forcefully stick with the Roadmap, we’d be ignoring the Feedback given, discoveries made and the Deviations themselves.
In this series, we’ll explore what Roadmaps and Deviations are. By diving into both, we’ll find out why Roadmaps are beneficial and what within them is non-beneficial. By the end of this series, we’ll have proper tools to help us plan short and long term Roadmaps.
[Note (August 2022): while researching on another matter, I came across a methodology called Adaptive Software Development, which from its description sounds very similar to the concepts about to be presented and practiced in this series.]
Creating Deviations
At RapidAPI (2021), first there was a UI/UX design and only then a Roadmap was made for it. It was for version 2.0 of the API Consumption Tracking dashboards. The designer and PM have invested weeks of effort into it. Finalizing every thought and every Detail.
When it was handed over to us at the Monetization R&D team, the hand-off was made of about 40 Zeplin screenshots. Each one had every little Detail a developer needed in order to code it. As it should.
As we were expected to deliver what we commit to, I saw there is no way the entirety of the design can be done within a single one-month Sprint. I sat down with the R&D team and our designer and we’ve divided the design into 15 Deliverables.
Combined, they were estimated at 4-5 one-month Sprints due to the complexity and our long fruitions delays. By doing so I’ve created a Roadmap, one the UI/UX design now needs to keep up with.
As expected, after each Deliverable a Feedback was given. It was both internal feedback between our R&D and designer/PM, and also external feedback by our end customers and the Customer Success team. Feedbacks which required us to Change the Roadmap. To create a Deviation from it. And these entailed Changes to the design.
Changing the design takes effort which we haven’t taken into account, and neither its consequences. For RapidAPI’s designer, it was updating 5-10 Zeplin screenshots which took her an hour or so. And she had to do so on every Deviation.
Some led to entire Deliverables be deemed unnecessary or without value, and they were dropped. Somewhere around the 8th Deliverable, the Deviations were so big they caused entire product and design concepts to change. It was an almost daily effort for the designer to continuously keep up with the Deviations, to Change all the Details again and again.
In the end, after all was delivered, the product looked similar to the design we started with, but was also very different in many ways. Different enough to wonder if the effort into finalizing the design in such Detail to begin with, ended up being a waste of the designer’s time. A cause of inefficiency.
Roadmap Uncertainty
Once there is a Roadmap there is something to Deviate from. And Deviations happen because Roadmaps are uncertain. The odds of a Roadmap going according to plan is inherently lower than we think.
This distinction could help us uncover what a Roadmap is, because not everything is or should be one. I think we can agree that two consecutive deployments or Deliverables are not a Roadmap. We can also agree that a 5 months plan to roll out 15 Deliverables is a Roadmap, whether we want it to be or not.
When we talked about uncertainties, we defined a Deliverable to be certain enough when it is 95% certain. We’ve also learned of the processes of Uncovering Work and Uncovering Effort to help us reach that level of certainty. Alas, 95% is the certainty of one independent Deliverable.
A Roadmap rolls out one Deliverable after the other. And a Roadmap’s certainty is dependent on each and every Deliverable certainty. Luckily, it’s easy to calculate it with a binomial distribution and just multiply the independent certainties.
Let’s think of a theoretical Roadmap of only two consecutive deployments or Deliverables. The odds of a Deviation is only 10%. Creating and maintaining a Roadmap for just two would be an overburden. On the contrary, The odds of a Deviation of 15 Deliverables, is more likely (51%) than not.
We can decide, based on the odds, whether or not a Roadmap would be beneficial or an overburden. It would be when the odds of Deviations are high enough for you. As I’m more cautious and conservative, a 20% odds for me would suggest a Roadmap is needed around 4-5 Deliverables.
Lets not forget that in reality, the 95% certainty may be a hypothetical one for us. It is based on the present state of the application/system/company at the time of estimation, at the time of creating the Roadmap. Estimations decay through time, and so does certainty. What we know and know how to do today, would become less relevant further down the Roadmap as it progresses.
We also presumed we actually made the effort to reach that level of Deliverable certainty. The more we neglect it, the more uncertain the Roadmap will be.
Effort into uncovering certainty allows us to deliver more without a need for a Roadmap. If the certainty is at 95%, we can safely have 4-5 Deliverables without a Roadmap. If certainty drops to 80%, we can not deliver anything without a Roadmap. And it would be a chaotic Roadmap as Deviations would occur very frequently.
| Certainty | Deliverables (Number, Odds of Deviation) |
| 95% | 5 (23%) |
| 90% | 3 (27%) |
| 85% | 2 (27%) |
| 80% | 1 (20%) |
Impact
When a Deviation occurs, a Change occurs. Question is, what will be the Change and how much effort will it take.
Let’s say a Deviation has occurred while working on the 5th Deliverable. It would definitely require Change to this 5th one, but we already planned and estimated for this incident.
And it may require a Change to work already done, past Deliverables. It would be to their design first and then it would be to the work already done, the coding. That is a Change to uncover and estimate, to make another Deliverable of.
Like every Change, it would be risky because it would have the potential to create an Instability. And the bigger and more Details the design and Roadmap have, the bigger the Changes will be.
These Changes are somewhat unavoidable, because Feedback entails Change. These are also intentional. One of the goals of diving into Deliverables is to have stop points for Feedback and Change. But there are those who are unitenional and avoidable, which happens because we relied on our gut feelings and haven’t done proper validation first.
Because the odds of a Deviation increases the further we go down the Roadmap, the higher are the odds to Change already done Deliverables. To re-invest effort into re-doing.
The longer the Roadmap is, the larger the potential for more Deviations to occur. And the more frequent Deviations are, the more times we’d need to Change the past Deliverables. Probably the same ones, more than once.
A Deviation can also Change the future work planned, future Deliverables. If a Deviation occurs while working on the 5th Deliverable, the potential to redesign several if not all future Deliverables exists. Which is exactly the continuous update RapidAPI’s designer had to make all the time. And the bigger and more Details the design and Roadmap have, the bigger the Change will be.
So maybe the problem with Deviations is not that they occur, but maybe it’s in having a too big of a design or a Roadmap, with too many Details. We’ll further discuss this in Detailing Disappointments, chapter 5 of this series.
But first, we need to consider another option to avoid Deviations altogether. There are no Deviations, if there is no Roadmap at all! Maybe it is more beneficial not to have one. On this, in the next chapter.