In the first part of this post I considered four ways a technology roadmap might come about. I dubbed them the bureaucratic, the defensive, the directive and the aligned. The aligned roadmap in particular is the ideal way to deliver the overarching organisational goal. Now in this post I’m going to suggest that…

Maybe you don’t need a roadmap

So those are all respectable reasons to have a technology roadmap. But there are also respectable reasons to not have a roadmap.

To start with, not all companies have a clear strategy which determines where it aims to be in the medium or long term. If our company is like this then we can’t produce an aligned roadmap.

(By the way, that doesn’t mean our company doesn’t have a clear driver. Steve Blank says that “the purpose of a startup is the search for a business model (not execution.)” So for startups at least it’s possible to have a strategy without it leading to a technology roadmap.)

Next, we might think about a directive roadmap: “my company doesn’t have a strategy or direction, so I’ll create opportunities and drive out a strategy or direction from that”. But as we saw before, that has risks associated with it, and ultimately the risks might not be worth the reward.

Then, we might recognise that our department is in quite a healthy organisational position, so doesn’t need to create a roadmap for defensive reasons. Good for us. No point making grand plans for the sake of it.

And finally, if no-one outside our team is demand a roadmap for its own sake we aren’t looking to create a one to satisfy bureaucracy.

So what are we left with? Not much material from which to create a legitimate roadmap. Now there are two options.

Option one: forget it, and don’t worry. We don’t have a grand plan, but it’s not as if there’s no work to do. There are still projects, bugfixing and general consultancy that needs to happen. And as long we don’t feel the need for structure in every aspect of our lives then we will find nobility in honest labour. In fact, most people’s work is like this.

Option two is what I’m going to call “lean roadmapping”. Just because we can’t produce a roadmap with several milestones it doesn’t follow that we can’t decide what the single next milestone is going to be. A plan with only one milestone is hardly a roadmap, but it’s certainly more than operational or project delivery.

As an example, we might see that the company is generally increasing its global sales, or that it’s broadly shifting to more corporate clients, or that customer responsiveness is tending to become more central to the business. There’s no explicit strategy, but there is a general direction nevertheless. It’s this kind of thing that we can respond to. Increasing global sales may mean increasing support for global working. More corporate clients may require a shift to a more robust infrastructure. Customer responsiveness may mean better integration of CRM-type systems.

By spotting a general direction we can work out our next milestone. In fact, it would be wrong to work out any further milestones: there isn’t a clear strategy and it would be an expensive mistake to act as if there was. We might line up a number of candidates for what might follow, but we don’t need to make a commitment immediately.

Lean roadmapping moves us forward strategically, beyond what a project or daily operations might do, but it does so without requiring wasteful planning or doomed prophesising. Only when we reach the end of this milestone will we determine the next one, and only then by reassessing the business context as it is at the time.

So in summary: There are a few reasons we might usefully create a technology roadmap, ranging from the not-so-great to the excellent. But while having a roadmap for the right reasons is a good thing, the best business solution may be just to plan one milestone at a time to honestly reflect the realities of an uncertain future.