In the previous chapter, we’ve seen that Blockages can be beneficial. If they are well designed and put with the right intention, Blockages can become Restrictions that prevent others from causing future inefficiencies. In a big enough system, placing all lots of Restrictions is a long time spanning and needs to be carefully planned. And we concluded that this is maybe what we call the Technical/Architectural Roadmap.
In this chapter, we’d wish to do the same but only with a more product/business perspective. To see what is the Product Roadmap, and how Restrictions would help us achieve another goal we have, to avoid execution of valueless tasks.
And lastly, although The Iterative Roadmap is excellent for execution, we’d come up with another kind of Roadmap better fitted and easier for long term planning.
Focus
Similar to coding, without Restrictions everybody can do whatever they want. Everybody will do so with the best intentions and no harm in mind. They will do so because theoretically they can solve any problem in the world. Our company can solve any problem in the world.
Obviously, that can not work for long. We wish to Restrict the company and our people to only explore a subset of all possible problems. To only a few at a time, one after the other. Restrictions can do this for us, to make sure everyone is focused on the problems at hand. Leaving the far future to the far future.
We wish to avoid Blockages, those who will prevent us or slow us down from resolving future problems. We wish to discover present and future contradictions and resolve them sooner than later. We wish to make progress while creating value out of resolving these problems. To break it down into smaller work units and goals, those who we probably call Milestones, which are Deliverables yet to be divided into smaller ones for iterative execution.
We already have the proper tool to manage Milestones, Deliverables, Blockages and Restrictions, that is the Roadmap. It allows us also to manage the fruition process, the relationship between time and value; To throttle the execution; to have stopping point for Feedback to avoid wrong rabbit holes; to better manage and prepare for Deviations and their impact; and to maintain the company’s Agility and keep it Lean.
And every Roadmap needs a guiding light, a non-final design/solution. In this context, that would be The Company Vision which would turn this into a Product Roadmap. And a big enough replan of it, is what we call a Pivot.
No reason not to use the same tool again, only for long term planning for the entire company for years to come. Well, except for one reason.
The Loose Roadmap
The Iterative Roadmap is a beneficial one for iterative execution. But it is also an overburden for long term planning, the one needed for Technical Roadmaps or Product Roadmaps. As those Roadmaps span for months and years, and maybe are actually never ending, a more dedicated tool is needed. Luckily, the Israeli Air Force already uses one.
First, let’s summarize what we don’t know, to leave out of the Long Term Roadmap:
- The Work that needs to be done, too soon to write User Stories
- The Effort the Work will require, there is nothing yet to estimate
- The Details, which makes it harder to Deviate.
- We know nothing of how the product will eventually turn out to be.
And let’s summarize what we do know, so we can build the Long Term Roadmap based on it:
- We know the product can change all the time.
- Long Roadmaps are highly uncertain.
- Present and future needs to explore, and they will change as well
- Deviations will occur.
- To do Validations and get Feedback as soon as possible, before we make a Change
- Time constraints due to external events, such as fund raising or launch dates.
- Dependency and order of execution
Our goal is to keep the impact minimal when a Deviation occurs, and it eventually will. To keep Change of past work minimal and to ease future replanning, which would make managing the Long Term Roadmap easier.
The basic building blocks of a Long Term Roadmap would be:
- Starting to work on B can only happen after A is done (dependency constraint).
- Starting to work on D can only happen after B and C are done (dependency constraint).
- A, B and C must be done before the Event happens or the Deadline reached (time constraint).
- C is independent from others (work in parallel)
- Starting to work on D should be only after the Event (focus and stop for Feedback).
- The Event or Deadline exact date – currently unknown or TBD.
Below is Silo’s 3 years Roadmap. It was done in 2017.
Let’s walk through it a little, to see the principles we learned in practice. The exact names of the Milestones were removed due to secrecy, but they were kept short. They had no details, only a “very high level” definition of either a technical prerequisite or a future feature. Both represented the needs or problems we needed to explore.
The first Event line, named Usability Test Delivery, made a clear distinction from the PoC stage to the rest of the Roadmap. The second and third Event lines (Device Manufacturing and Device at Home) helped us remain focused on the immediate necessities. First, hard prerequisites that without them no product can exist. Only later, priority wise, we should start fulfilling the more end-customer experience related. Beyond the third Event line, are only Milestones to be kept at mind that are yet to be Detailed or invested in.
Due to manufacturing delays and new knowledge gained, we had to Deviate more than once. Because we remained focused on the necessities, there were no Changes to past work. And the future ones, they were still on paper, which is the easiest to Change. It was just moving blocks and event lines.
Practice
Prepare the following:
- Make a list of your goals, Milestones, needs to explore and problems to resolve.
- Draw several vertical dotted lines, the Events and Deadlines. Such as “PoC done”, “Product launch”, “Series B”, etc.
Create the Roadmap:
- Place only the goals that must be done before the Event, to its left.
- If it is a “business goal”, it should be as soon as possible, at the most left of it.
- If it is a “technical goal”, it should be placed as late as it could actually be, as close to the Event line as possible.
- Place, move and remove the goals until it makes both business and technical sense
- Example: having a MVP mobile app to download is a must at launch, other prime features can be technically done at the end.
- For each goal, make a list of required projects from the start(!) to the end(!). Place them on the chart and link them with arrows. Two kinds of lines can be used to describe two kinds of relationships:
- A technical dependency black line
- “Effects The Details” green dotted line.
- Optional: color these projects according to field/expertise (e.g. backend v.s. Front end v.s. BI etc).
- Move goals and chained projects between the event lines as needed.
Execute the Roadmap:
- Keep everyone focused only on blocks relevant to the upcoming Event/Deadline.
- Keep everyone only aware of the future blocks, those after the upcoming Event/Deadline.
- To execute the series of blocks, use The Iterative Roadmap. That will create a design/solution for them and iteratively discover the Details required to get them done.
- When a goal has been fulfilled or after the Event/Deadline has been reached, Deviate. Re-assess and re-plan the Long Term Roadmap with all the knowledge you’ve gained so far.
And that’s it. We’ve got everything and every kind of Roadmap we need in order to correctly run projects, from spanning years, to weeks and months, to spanning days.
Thank you for reading this series, I hope it will be beneficial for you.