In the previous chapter we talked about Deviations, that once a Roadmap exists those 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.
When we plan only one step at a time, the view above is always a snapshot in time of 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. 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 existed in the code, one that was unawarely added sometime in the last six years. One that needs to be removed today, or else we can not 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, of us from coding another Blockage to be removed by someone else a few months from now. It is possible to avoid it today, but 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, who is to say what we should be aware of? Well, that would be me. “Guys, I’m sorry but the solution we ended up with contradicts the Roadmap”.
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 a few hours earlier, or luck if we may, 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.
If I would not have coincidentally been to that Sales meeting, I would 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 technical prerequisites, Blockages to be removed before moving the business forward. With one, 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 backend service that would support this function. 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 an end 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 these Roadmaps.
Not everyone was on board with this and the CEO had not changed any Roadmap, but we knew enough to keep ourselves 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 reason to do so intentionally, and it is always beneficial to avoid valueless execution. We went with an option that would not create a Blockage 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 said earlier, not having a Roadmap is always looking at one step at a time. From the Current State to the Suggested State and maybe have an unexpected intermediate Unblocked State. But 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 steps were taken, the application has gone through many states. And as such 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 through time and 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 one, it is having a beneficial one that we can commit to without creating future disappointments. On that, in the next chapter.