/ software

Software Roadmaps

I've been working for a while on a new way of answering the roadmap question. Which for those of you who haven't worked in a company like this goes something like:

Can you send me a copy of your roadmap?

In it's first iteration it's always devoid of information, like why, what are you going to do with this. The assumption however is always, there is a single document called a roadmap, that I can use to do whatever I want with.

Often these people will go away when you ask them any sort of question of your own, but in a lot of organizations, roadmaps are poorly understood, and not worth the paper they have been printed on, let alone the time in that laminating machine that one guy from sales has on his desk for some reason.

It's already about 4000 words, so I'm going to start breaking it into installments, the first of which is:

Your road mapping and planning process is stealing your best ideas.

It's killing them in the name of false certainty.

"Wait!" you say, "You don't know anything about our road mapping process. Ours is great!" True, I don't. I'm still right though, let me tell you why.

A roadmap is an attempt to produce a level of long term visibility into your product, to lock scope into place some number of months ahead of time. This visibility, the thinking goes allows the whole company to get aligned with a set of long term events. "It sounds great. I mean, sure, we just spent a million dollars on our agile software transition but alignment and long term strategy!"

Unfortunately the transition from alignment to anchor happens before the ink is dry. These anchors end up being driven by your best, well intentioned thinking at the time, but the very process of making decisions about something more than a few weeks out creates fixed points in scope and time. Then you communicate them for that much vaunted alignment, and you set them in stone.

expectations

The benefit of agility and team based software development is that your best thinking on a a problem happens close to the team, during the development itself, or in the time between iterations, the team is making lots and lots of small decisions based on data to deliver the most value, or best outcome. Successive approximation toward the goal.

The other fundamental problem with roadmaps is that each one is ultimately an attempt to make something inherently complex into something simple and readable. Complex things distilled down to a single page of dates lack the needed context. It's a narrow one dimensional view of your future, subject to interpretation, and often misuse. This can quickly move your roadmap from an alignment tool to something with a high potential to damage your relationship with customers and internal partners.

In a perfect form, one where all risk was resolved, and we had complete knowledge, a road map would be a beautiful thing. All your questions could be answered. In the real world however, we don't have that complete knowledge, and it's important to recognize it. The failure to keep expectations aligned with the facts on the ground is responsible for a great many product disappointments, how do you protect against these disappointments when you have boiled your next several years of work down to a series of quarterly dots?

Typically road maps are also completely divorced from why questions. This further limits the usefulness of the road map as a tool. How can you look at a multi-year roadmap and make a good/bad decision?

Ultimately, to be worth the paper it's printed on, a roadmap is something you earn. As teams and products develop, your planning and prediction horizon should expand. It becomes safe to make a commitment as a team, because you know your history, and understand your product more completely. You earn that predictability, and the ability to talk about what you are doing and why with your hard work.

The question is what can you do instead to satisfy management that doesn't want to deal with the complexity, but not break your product or your team on these expectations.

Many people start solving this problem by aligning with goals. There is nothing wrong with that, but goals are only half the story. Further a goal is a tough thing to calibrate at the right level. They are too big, too small, too vague, and they are missing the why?

Up next: Motives