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.

When starting a project, always do it in this order:

1. Identify the Objective: Define what’s important. Literally write it out. Be as vague as you need to be. “This thing needs to be fast” and “We must get 15% market share” are both completely fine ways of stating what’s important, and will vary depending on the project.
2. Identify the Source: Figure out how to measure those things objectively and accurately. Is it counting logs, counting orders, or receiving a report from a third-party?
3. Set a Baseline: Start measuring and reporting on those things right now. Could be “0” if it’s a brand new initiative, and that’s fine. Just measure it and report on it.
4. NOW talk about how to change those numbers.

It’s completely useless to spend time building something if you can’t, or don’t know how, to measure it’s effectiveness. You’ll end up spending a lot of time over-analyzing “feelings” or over-engineering a solution.

Mostly a reminder to myself. 

There are four basic attributes to measure the health of your Scrum team:

The team’s priority and vision is clear and understood.

• It’s working if: you ask anyone on the team to describe the roadmap and they all answer the same way.
• It could be better if: your team is struggling with communicating the vision concisely. Consider publishing your roadmap/strategy document and sharing it with your team.

One team is responsible for the entire development process, from design to deploy.

• It’s working if: the entire team feels heard in decision making and is responsible for delivery of a quality product, soup-to-nuts.
• It could be better if: design work waterfalls into development, or development waterfalls into QA. Both of these cause frustration that can be solved simply by involving them in your Scrum meetings.

The team estimates work to clarify effort, not to predict timing.

• It’s working if: the team estimates that this “feels like a 3’s worth of effort“. Your team breaks down work into manageable chunks and assigns an estimated level of effort. The team understands that they can’t predict the future, and does not attempt to estimate the length of time necessary to complete the work.
• It’s not working if: the team estimates that this “feels like a 3’s worth of time“. It’s important that your estimation meetings don’t become project management sessions, and especially important that you don’t attribute x story points to x days of work. Ask the team to take timing completely off the table in grooming meetings.

The team does not assign arbitrary deadlines.

• It’s working if: the team sets the deadlines. They understand that urgency is a limited resource and should be used only when necessary.
• It’s not working if: your team feels like it is having problems finishing work “quick enough”. Consider pushing back on external sources that are asking for a completed date, and over-communicating progress and blockers. Remember that it’s probably not that your developers are slow.

Development speed is important, but make sure your primary focus is on the result.

There was a contest where contestants had to find a box in a forest based only on a photograph of an item. There were two contestants. One was a spry young man who has never been to this particular forest. The other was a limping 60 year old woman who has lived nearby and knows these woods like the back of here hand.

The pistol fires and off they go. The young man takes off running. He runs here, runs there, runs circles, looking for something familiar from the photo. His endurance is uncanny and his ability to jump across branches second-to-none.

The lady looks at the photo and studies it. After a few minutes, she takes her walking stick and limps off. She recognized the rocks in the photo and knows more or less where to go to find the box.

The young man is much more productive in “miles ran per hour”, or “acres searched”, or in “O2-consumption-per-mile” metrics. For the lady, the above metrics are dismal.

However, she beats the man in the most important metric: “boxes found”.

It’s tempting to track how much work your team is putting out. Your team could be writing the most lines of code (“miles ran per hours”), or closing the most defects (“acres searched”), or deploying the most stories (“O2-consumption-per-mile”). But if those changes don’t affect the one metric that matters (“boxes found”), then you may want to reconsider what metrics are worth tracking.

Product managers can effect change today by using the same techniques that effective executives use.

Effective executives are great at playing politics. They’re continuously in meetings with decision makers, stakeholders and other teams to ensure that their idea is bought into and successful.

But executives don’t call it playing politics. They call it collaboration – and this is the key to getting things done when you need buy-in from people who don’t report to you.

Product managers are in a similar position. While we’re not CEOs (despite what the Internet wants you to believe), product managers are responsible for the ultimate output and typically don’t have direct line responsibility for the people doing the work. I heard someone describe being a product manager as “all the responsibility with none of the authority”.

Effective executives don’t dictate what to do. They get people on board using a combination of persuasion, collaboration and tact.

Since product managers usually don’t have the ability to hire and fire our team members, we need to rely on the same techniques that effective executives rely on to get a team of people to do the right work at the right time:

• Persuasive executives (and product managers) don’t have all the answers, but they know all the problems. When collaborating with another team, come to the table with crystal clear problems instead of answers. Engineers and designers are paid handsomely to solve problems, so unleash them on it. Not only will they use their brainpower to solve the problem, they’ll feel ownership over the deliverable (instead of pushing back against your solution out of ego).  BONUS: this is a great example of getting out of your team’s way.
• Collaborative executives (and product managers) add value to other teams. Whether it’s offering to let another team borrow an engineer to get that feature deployed or creating the slide deck for an upcoming group presentation, collaborative managers add value to other teams by offering to help however they can. BONUS: It’s so common in our profession for the default answer to be no, that you may garner good-will just by offering.  
• Tactful executives (and product managers) make sure nobody is surprised. Have quick, informal meetings with individual members of your team before announcing a change to the larger group. These short “pre-meetings” let you receive and react to feedback privately while showing that you care enough about their opinion to ask for it before finalizing your plan. By the time you’re ready to announce the change publicly, literally nobody is surprised. You’ve now successfully steered conversation at the announcement meeting to how it’s done, and not whether it’s a good idea. BONUS: These are great topics for conversation in 1:1’s with your team.

Thanks to fellow product manager Stephan Rubin for reading an early version of this.

Your roadmap is about direction, while your project plan is about speed.

Roadmap: where are we going and how do we think we’re going to get there. This is primarily driven by business strategy. (see: How to format your roadmap to foster cross-team alignment)

Project plan: when should we get there. This is primarily driven by resources and velocity.

It’s easy to conflate your roadmap with a project plan, but they are fundamentally different tools that are essential to creating your product backlog.

Focusing too much on the possible makes it improbable that you’ll solve the impossible.

As a product manager, it’s easy to automatically scale back the discussion to what’s possible. After all, you’re the one responsible for the timeline, the cost and ultimately the success of the outcome. So, it’s safer to push something good out now than to push something amazing out in three months.  “Nobody ever got fired for buying IBM”, they say.

However, you should come into the strategy session with the craziest idea to make your product better, and then let your team talk you out of it.

To experience real product growth, spit-ball those crazy discussions with your team. Don’t accept that “it works this way and it’s too hard to change” (especially when you’re the one saying it!). Talk about why it’s that way, how to work around it, ways to make it better, and what you would do with infinite time and resources.

Your team will only think as big as you do, so push yourself to think bigger. If you come in with constraints and excuses, you’re handicapping some talented, expensive creative talent.  The alternative is shipping small iterations (“quick wins!”) in the short-term, and that’s neither fun nor effective.

In an ideal world, you’d make an informed product decision backed by data, feedback and intuition. But you can still decide with only two.

If you only have DATA + FEEDBACK: your customer base is telling you something that surprises you. You’re solving their problems today, but make sure you’re considering the bigger picture. Dig into that data to validate the feedback you’re hearing and to predict the problems they’re not telling you about. You should understand what your gut is telling you and try to figure out why it’s not aligned with the data.

This week: spend some time getting a better understanding of your market. Install Intercom and contact leads that didn’t convert to understand why.

If you only have DATA + INTUITION: Your computer is telling you something different than you’re hearing from you customers. Don’t discount this immediately. Your customers may not know what they want, or you may not be asking the right interview questions.

This week: build an MVP with Invision or Squarespace, and attempt to validate it with your personas.

If you only have FEEDBACK + INTUITION: You’re certain that you’re onto something, but the skeptics don’t believe you. You’re either on the cutting edge of a breakthrough, or you’re way off in left field. Is it because your data is garbage, or you just don’t have enough?

This week: send an NPS survey or add Mixpanel tracking to quickly (and objectively) validate what you’re hearing.