We finished the previous chapter acknowledging there always is a Roadmap, so there would always be Deviations from it. It’s only a question of whether it’s a Roadmap we planned and anticipated for Deviations, or a Non-Roadmap that controls us and leads us to unawarely continuously add and remove Blockages.
We concluded that having a planned Roadmap is more beneficial than not having one. In the next few chapters, we’re going to discuss what makes Roadmaps more beneficial, or more correctly how to avoid the troubles and traps they present.
In this chapter, we’d be talking about expectations and uncertainty. When we commit to a Roadmap, we commit to an estimation of it. But the longer the Roadmap is, the more uncertain it is.
Thus commitment lays the seeds for future disappointments. And when it occurs, and we know it will occur, a Deviation triggers an already laid disappointment. Let’s see how those can be reduced and avoided.
Magnitude
It is possible for a single Deliverable estimation to be certain enough. But setting a Deadline for Roadmaps is problematic at best, because they are inherently uncertain, and certainty decays with time.
Committing to a delivery date based on the sum of all independent estimations would be wrong. But it can give us the magnitude of it.
At Silo (2018), we finished a successful Proof of Concept. We knew a lot about what needs to be done to turn the PoC into a final product, a production-grade and manufacture-grade one. And it needed to be done from scratch.
The CEO, who had no background in software, expected that because the PoC took 1 year, all we need to is to double the personnel it would take half the time. 6 months instead of 1 year. We’ve done the process of Uncovering Work and Uncovering Effort and got our estimations.
It was far from it. How disappointed was he to learn it would take 15-18 months, maybe. The company did not have enough funds for such a long effort. He had realized he would need to raise more funds, otherwise it would end before it started.
He managed to do so, but unfortunately not enough was raised. The company had to shut down about three weeks before the software development ended, which would have put the actual execution time at 16.5 months, almost as expected.
Hitting such an estimation was not luck, but it might have been coincidental. Because the Roadmap was long enough to allow such a coincidence to happen. I can guarantee you that if we would have tracked it, almost no estimation had been right due to many Deviations. The Deliverables that had taken less time “covered” for the ones that took more. That may have been a reason the estimation ended up being accurate enough.
But honestly, give 6 engineers 16.5 months and they can accomplish every beneficial Roadmap no matter what it holds, if we just allow them to do their best.
Constraining Roadmaps
Committing to a roadmap, is creating a Deadline for it and setting expectations. For a Roadmap longer than 4-5 Deliverables, is would also be creating a potential disappointment.
But sometimes, someone had already committed a Deadline to a customer. Or we have already committed to deliver something by the end of a Sprint. Fortunately, we can use just that to bridge the gap of Roadmap uncertainty.
At RapidAPI (2021) we had a committed to deliver a very complicated feature. The Roadmap we worked on was content based, content constrained. It’s goal was to have at least one Deliverable done every Sprint, and it mattered less how many Sprints it will take:
The first Milestone was all about removing Blockages because before then there was a Non-Roadmap. And just as we delivered the first one, we got some news from our Product Manager.
Unexpectedly, due to business related needs, we found ourselves required to release this feature within a month. Otherwise, there would be a three-month delay to an already expecting customer.
We barely started with the second Milestone, and the customer expected the last one. The rest of the Milestones were all about fulfillment of customer needs, which can not come to full fruition within a month.
It was decided that no matter what, we must deliver something beneficial within a month. We had fenced the effort. It was more than a simple Deviation to the Roadmap. It was a Change to the entire Roadmap’s, replanning it with atime based constraint – all Deliverables must be done by a hard fixed Deadline.
For a Roadmap, just like with every Task or Deliverable, a time constraint changes its design/solution and content. Naturally, we reduced customer expectations to a bare minimum. We made sure the estimated effort would hit the Deadline constraint as well.
With the new Roadmap, we kept on making sure no Blockages will be added. We designed our solutions to ensure the rest of the customer expectations can be delivered sometimes later. Because there would be a next version someday.
Not coincidentally, the Roadmap for the immediate version ended up consisting of 4-5 Deliverables, shorter thus more certain. Something to commit to, which we did and we got it done perfectly. Customer disappointment was avoided.
Unfortunately that is not 100% correct. We have only avoided the disappointment of not meeting a promised Deadline. As we shortened the fruition process, we soon found out we ended up in the wrong rabbit hole.
The customer was disappointed with what was delivered, as it did not fit his needs at all. It was a huge miss. The team itself was highly disappointed, as their effort was for nothing.
I wasn’t disappointed, I was actually quite happy to be in this rabbit hole within a month and not within six months. A lot of time saved, and a much bigger disappointment avoided.
I found it to be beneficial in the end. So why not always iteratively commit only to the next few Deliverables? On this, in the next chapter.