In the previous chapter we talked about Deviations, that once a Roadmap exists these occur. And once they do, it would require us to Change the work we’ve already done, and to Change the design and Roadmap of the work to come. We’ve ended the talk by wondering whether it is beneficial not to have a Roadmap at all.
In this chapter, we’ll explore this Non-Roadmap. Through the consequences of having one v.s. non, we’d try to better understand what a Roadmap is, when is it needed and why.
Chasing Pavements
There were times at RapidAPI (2021) where we did not have any Roadmap, supposedly. The Monetization team had started working on a new feature that required multiple Changes to the company’s authorization logic, some were quite deep. We met with the Authorization team and their PM and came up with a satisfying solution ready for a design review. Changes that would take the application from today’s code to tomorrow’s code.
The view above is an in-time-snapshot, just before any required Change. One that takes an application or a system from the “Current State” to the “Suggested State”. When we plan only for one step, our minds do not consider that more steps would eventually come afterwards. It is always so when we plan only one step at a time.
As there is nothing to plan according to, this could lead us to unawarely or unintentionally code a Blockage. Which is exactly what we were now facing at RapidAPI. A Blockage was added sometime in the last six years, and we just found about it. At the worst possible time. Without removing it now, we cannot take the application to its Suggested State.
We also have no Roadmap today, just like the others did not have many years ago. Nothing today prevents us from making the same mistake again. Nothing makes sure we wouldn’t be coding another Blockage, to be removed by someone else a few months from now.
It is avoidable today, thus not doing so would be just creating another future inefficiency. Exactly like someone in the past did for us unintentionally.
But in order to avoid something, we must be aware of something. And if there is no Roadmap, what would be telling us there is something we should be aware of? Well, that happened to be me. “Guys, I’m sorry but the solution we ended up with contradicts the Roadmap”. What a twist!
Traffic Lights
I hope I caught you, the one who read this, by surprise. The teams were surprised even more than you to know that a Roadmap exists.
Coincidentally, or luck if we may, a few hours earlier I was called into a meeting about Authentication with someone from the Enterprise Sales team. An hour into the meeting it naturally slipped into Authorization, as the two subjects are closely related. We were shown the future of RapidAPI’s Authorization, something very similar to the SalesForce model that our future enterprise clients are expecting.
Without attending that meeting, I would not have been able to raise my hand and say “it contradicts the Roadmap” in the design review meeting. If I wouldn’t have raised my hand, for sure we would have created a Blockage and an inefficiency.
A Roadmap is a tool that potentially prevents Blockages and future inefficiencies, by creating awareness to the future. Without one, we’d be constantly finding ourselves with Blockages to be removed before moving the business forward. With a Roadmap, the odds of it are reduced.
At Silo (2018), after a successful Proof of Concept, we were more than halfway into the final version of the product. Silo was supposed to manufacture deep vacuum containers, and its primary feature was their storage managed by Alexa and a mobile app.
We were about to model the data in the supporting backend service. We were discussing whether the Food Object should be nested within the Container Object or vice versa. Supposedly something trivial, which turned into the most amazing discussion.
We had a technical Roadmap, an amazing design and also a Long Term Roadmap (which we will learn how to create by the end of this series). None of them have ever addressed the question of what are we really managing, Silo Containers that have Food in them or Food that some of it is in Silo’s Containers?
The CEO and Founder, who was a very visionary person, said we should only manage Silo Containers. If there’s going to be food in the fridge we’re going to manufacture a fridge, and later he started designing a very innovative one. That is one amazing vision, because it’s better not to be a single product company.
But our Long Term Roadmap also included making money out of food replenishment services. If we were to lock ourselves only into food within our containers, we’d neglect about 85% of our customer’s food: Foods in their fridges; cupboards; and pantries.
It was obvious to me the Long Term Roadmap was contradicting itself, an observation that could not have been made without the existence of such Roadmaps.
Not everyone were on board with this and the CEO had not changed any Roadmap. But we knew enough to keep our options open to an optional Deviation in the future. When it came to the UI/UX design, it was merely a future Change to a label from “Containers” to “Food”.
But when it comes to a database, a future Change to the data structure would be a data migration. Our software engineers said it’s not such a big deal. Even if we are locked in now and we can unlock ourselves later, as the future unfolds. That is adding a potential Blockage, a potential future inefficiency.
There is no good reason to do so intentionally, and it is always beneficial to avoid valueless execution. We went with a technical solution that would not create any Blockages, even in the face of a potential future Deviation.
Roadmaps allow us to plan for Deviations. Without it, how could we have known that a simple data model holds a potential to cause a time waste?
There is always a Roadmap
As we mentioned earlier, not having a Roadmap is having a one step at a time view. From the Current State to the Suggested State, and maybe have an unexpected intermediate Unblocked State.
This time instead of looking into the future step, let’s look back at past steps. Many steps were taken since the day our application was born, to its Current State we are looking at today.
If past steps were taken, the application has gone through many states. And as steps were taken, Changes must have been required. New versions must have been deployed. If something was deployed, something was delivered. It might not have been correctly or intentionally divided Deliverables, but they were done one after the other. Progress was made.
There always is a Roadmap. Question is will it be one we see, plan and manage and prepare ahead for Deviations; Or will it be a Non-Roadmap, which would lead us into a state of uncontrolled inertia, continuously unawarely and inefficiently adding and removing Blockages.
It’s more than just having Roadmap, it is having a beneficial one that we can commit to without creating future disappointments. On that, in the next chapter.