04 The Winding Road

Roadmaps have an internal contradiction. They set up a path for us to walk on, and the path always changes. If we stick with the Roadmap’s planned path and not walk on the actual path we lay, we’d end up at the wrong rabbit hole. Because on every step we listen to every Feedback given after a Change, the path changes while we walk on it. We Deviate from the original planned path. And the ever changing path is the one we should walk on, in order to get to where we are supposed to be.

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.

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.

define and practice a Roadmap based on shorter commitments. To iteratively commit to roughly 4-5 Deliverables with higher certainties, while keeping the Roadmap in mind to avoid Blockages and disappointments.

In this chapter, we’ll deep dive into the Details themselves. We’ll see why they are another source of disappointments, one out of commitment to content and design; And we’ll see why they are also a source for potential Blockages and inefficiencies. Through both, we’ll learn how to make our Roadmaps even more beneficial.

So far in this series, we’ve talked a lot about Blockages, code and design decisions that later need to be Changed or removed in order to continue to make progress. A source of inefficiency. We’ve treated them as something that is necessarily evil, something non-beneficial. We’ve looked at them as an unwelcomed and unintentional outcome. But using them correctly and intentionally, we can leverage Blockages to our own goals. To use them as a Restriction to others, to prevent them from causing future inefficiencies. And that would be beneficial.

In this chapter, we’d wish to apply Restrictions 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.