We can actually increase team alignment by throwing out most of what we communicate through roadmaps.

In every team I’ve been on, the highest functioning teams have been the teams with the clearest focus and understanding of our goal and our strategy.

And probably just like you, to accomplish that alignment, I’ve always relied on some semblance of a roadmap.

ROADMAP: a list of stuff we wanted to accomplish, and when we would do it.

Let me be embarrassingly honest for a second:

I. LOVE. ROADMAPPING.

It’s really fun to think about everything we should (and could!) be doing to make progress towards our long-term goal. It’s really fun to think about what order they should go in and about how long everything should take.

As I work on my roadmaps, I always imagine people rallying around the “living, breathing document” with crystal-clear purpose and understanding of where we’re going, why we’re going there and when we’ll be able to celebrate our successes. In my mind, they’re pumped, they’re ready to do good work and solve some important problems.

The thing is: nobody reads a roadmap.

• Realistically, you present it to your team and it sparks some conversation, but that’s the last time they look at it.
• Your manager reads it when it’s review time and says it’s great (or to change everything).
• Maybe even a couple of people stumble on it when they’re searching for something else.

But that’s about it. By and large, the roadmap is a doc created for everyone, and ultimately enjoyed by nobody.

We spend too much time creating roadmaps

Roadmaps help communicate vision and strategy. We want to make it obvious to the groups that rely on us that we know where we’re going and how we plan to get there. When I create a roadmap, I think about three specific groups:

1. My team, so they know where to march today and tomorrow.
2. Other related teams (other teams in your group), to communicate what direction your team is marching in, so they know where to intersect or avoid your path.
3. Everyone else (customer service, marketing, etc.), so they can plan for your arrival.

So, we tell each of these groups that we’ve created this grand document for them that will solve all of their problems: the roadmap!

But all of us know the truth:

ACTUAL ROADMAP: a list of things that we plan on delivering over the next year or so that’s immediately out of date as soon as you publish it. Plus, nobody reads it anyways.

However, the problem still exists: how do you keep your team, other teams and everyone else aligned without a roadmap?

Let’s be honest for a second: your team is primarily focused on what’s most important today. We’ve got value to deliver in this sprint or quarter, and a group of really smart developers, designers and QA that are working hard at it. They may be curious what’s coming up later, but by and large, they’re mostly concerned with today.

Outside of your immediate team, most others are less interested in the details than you think. Other teams in your group are interested in what direction you’re headed, but one page on your company’s wiki isn’t the only way they’re going to get that information.

A roadmap has never stopped a meeting from happening, and that’s not going to change today.

Software development teams especially know that development can take longer or shorter than expected because stuff happens: customers hate the first version, dragons are unearthed during development, the group or company strategy changes, or people leave.

And when stuff happens, your roadmap is out of date immediately.

News flash: neither your team, your group, nor any other group expects you to be able to predict the future.

Seriously, how often have you shipped something when your roadmap said you would? Do you know anyone that ever has? Talking to a friend who’s an  “engineering management consultant”, he said that on average, most software projects end up 60% over schedule. Multiply that stat by every project on your roadmap, and even the best project manager would only ship half of what was promised when they promised it.

So:

• Your roadmap is list of features you expect to deliver in the future
• But your team is focused on the present
• Few others care about the details (if they know your roadmap exists in the first place)
• And the dates are more-than-likely wrong

You published a detailed roadmap to create alignment, but it turns out that roadmaps full of features and dates create more work, headaches and misinformation than alignment.

But we can all agree that communicating our vision and strategy to get there is important for the team and for others. How can we do that if we’re killing roadmaps?

Instead of killing roadmaps entirely, let’s make them more useful. Instead of creating a roadmap that looks like a project plan, let’s overly-communicate our vision and strategy.