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 either one we planned and correctly understand their upsides, or a Non-Roadmap that controls us and leads us to unawarely continuously add and remove Blockages. 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 uncertainty 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. We’ve done the process of Uncovering Work and Uncovering Effort and got our estimations. The CEO, who had no background in software, expected that because we doubled the personnel it would take half the time. 6 months instead of 1 year. It was far from it. How disappointed was he to learn it would take 15-18 months, maybe. He realized he’d need to raise more funds to make this happen. He managed to do so, but eventually we ran out of funds. The company had to shut down about three weeks before the software development ended, which would have put the actual time at 16.5 months, as expected. It was not luck, but it was coincidental. Because it took long enough to allow such coincidences to happen.
As we walked down the Roadmap many Deviations had occurred, mostly ending with changing priorities and some Changes to future Deliverables. I can guarantee you that if we would have tracked it, almost no estimation had been right. The Deliverables that had taken less time “covered” for the ones that took more. That may have been a reason the estimation was 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 long Roadmap of more than 4-5 Deliverables, and expecting it to be done on time as planned, is creating a potential disappointment. If there is a strong need to meet a Deadline, we can use it to bridge the gap of Roadmap uncertainty.
We’d be doing so with techniques we’ve learned of before. One would be to affect the design/solution by constraining it to a Deadline. The other would be to fence the effort, which we used to handle Predictable and Highly Uncertain Tasks.
At RapidAPI (2021) we were facing a problem. The Monetization and Authorization teams had a very complicated feature to deliver. Unexpectedly, due to business related needs, we found ourselves required to release this feature within a month, or suffer a three months delay to an already expecting customer. It was decided that no matter what we must deliver something beneficial within a month.
The Roadmap we worked on was content based/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 there was a Non-Roadmap before then. And it had just been delivered when we got the news. The rest of the Milestones had customer facing effects and fulfillment of customer expectations, which now can not come to full fruition within a month. We barely started with the second Milestone, and the customer expected the last one.
It was more than a simple Deviation to the Roadmap. It was a Change to the entire Roadmap’s future plan, with a time based constraint: All Deliverables must be done by a Deadline, which must be a fixed number of Sprints.
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. But because we work with Roadmaps, a little bit more than the bare minimum was done. It required more effort to ensure no Blockages would be added, and a different kind of design that ensures the rest of the customer expectation can be delivered sometimes later. All while making sure the estimated effort would hit the Deadline constraint as well.
Not coincidentally, the Roadmap for the Immediate Version ended up being shorter thus more certain, 4-5 Deliverables. Something to commit to. And we did and we got it done. Disappointment was avoided.
Unfortunately that is not 100% correct. We have only avoided the disappointment of not meeting a promised Deadline. As it 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. 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. If that is so, why not always iteratively commit only to the next few Deliverables? On this, in the next chapter.