Roadmaps are Useless, but Roadmapping is Essential

Let me tell you a story. It’s one that I’m not proud of but if it hadn’t happened, I wouldn’t have learned a very valuable lesson.

Spoiler alert: you may never build roadmaps the same way again.

I’d been on the job for two months. I was brought in to lead the Product and Technology Departments of a medium-sized company. It was a big job, but I felt prepared for the challenge. What I wasn’t prepared for was the CEO’s unexpected question when we sat down to walk through my vision for the product roadmap.

Weeks earlier, I’d joined the company and began learning everything that I hadn’t picked up on during the interview process. I met people, looked at reports, and gathered context. In a few weeks, I’d be putting together my own vision and roadmap for a roadshow throughout the C-level team. During that roadshow, everyone would give me feedback. Change this, focus on that, he’ll want to see this (he, being the CEO). I frantically iterated my way through my slide deck with each meeting, sometimes going in circles.

Then came the day I was to present my roadmap to the CEO. I was nervous, mainly because everyone else seemed so nervous for me. But I felt good about my plan. I thought I’d done my homework by speaking with all the internal stakeholders. I thought I was ready.

We sat down together, and when I turned to page two of my printed-out slide deck, the CEO asked me a simple question that changed everything.

“Is this what our customers want?”

At that very moment, I came to the realization that I actually didn’t know what our customers wanted. The idea he was asking about was supported by everyone else I’d met with up to that point. They all thought it was a good idea. The idea was an online community with an element of gaming and rewards. It sounded great. I’d put lots of effort into fleshing out the idea, but I’d put very little time into learning whether this was something anyone needed or wanted. Exactly what problem was this solving? I couldn’t really say. Was it just another solution in search of a problem?

I did my best to recover from the grenade that was thrown into my confidence bank. Then I answered the CEO’s question honestly. I told him that while I thought our customers wanted this to exist, I couldn’t be sure. I admitted that we needed to validate this thinking by doing more research and testing. He nodded with a mixture of disappointment and appreciation. Disappointment that I hadn’t already done that research. Appreciation that at least I was honest in my response. I fumbled through the rest of my plan and left his office, feeling like I’d wasted weeks on the wrong things.

This experience helped me realize something that had been building inside me for years. Solution-based roadmaps don’t make sense. Yet, they are standard in most companies. I didn’t realize that this company was different and so was their CEO. I’m grateful for both.

That day I learned that there was another way to build roadmaps. The way I’d known typically went something like this:

A team is formed. A leader of the team is identified. That team leader reports to someone higher up in the organization. That higher-up person says they’d like to see a roadmap for the product or service area that the team leader is leading. Someone schedules a “Roadmap Review” in the calendar for a few weeks or months out.

Imagine you are that leader in this scenario. You get to work. You review existing feature and task lists, project request forms, tickets, dashboards. and user stories. You think about what you could add in to really make a difference and leave your personal stamp. Now you start thinking about how to visually convey all of this in a roadmap. Should it look like a timeline? Maybe something playful that looks like the Yellow Brick Road from The Wizard of Oz? Maybe it’s just a spreadsheet with features and dates? Which software tool could you use? There are so many. You spend a lot of time playing around with different ways to visually represent this roadmap. You discuss it with your team. You agonize over how much detail to include. How much is enough? You review it and refine it. Eventually, you present it to other people. They react to the ideas conveyed in the roadmap. You note this feedback and iterate further. After all of this, the purpose of the roadmap seems lost. Instead of it being a way to organize work and resources, it has become a document that gets examined in meetings — mostly with consideration to the end game of a meeting with the CEO or someone else in charge. The roadmap is simultaneously locked in stone and completely changeable, depending upon who asks. Why? Because it’s totally solution-based. It’s based on loads of unvalidated assumptions. It gives comfort in the moment, but it never really serves a long-term purpose.

Good news! There is a better way:

Create a problem-based roadmap.

Here’s the scenario above, retold with a problem-based focus.

You review existing feature and task lists, project request forms, tickets and user stories. That gives you a starting place for your user research. You meet with the users and learn about their experiences and behaviors. You capture insights along the way. After five to ten user interviews, you begin to synthesize the data you have acquired. You begin to see patterns. What are the pain points? What needs are not being met? Simultaneously, you conduct user tests with anything that already exists. You consider any pre-existing data, but don’t take it as fact. Rather, it serves a directional purpose, indicating where you might dig deeper. For example, if you see that customers have a high exit rate on the third step of your purchase flow, you schedule user tests that will allow you to watch people make their way to that third step. What do they say? How do they view it? Why are they stopping there? You learn.

You do this repeatedly and collect a series of problems to be solved. Each problem or need might be captured in something called a “user story”, but I like to be even more specific and call them “problems to be solved” or “needs to be met”. Language matters.

Option A:

User story: “As a subscriber, I want to see how many credits I have at all times, so I can make informed decisions about what I download.”

Option B:

Problem to be solved/Need to be met: “As a subscriber, I always worry if I am nearing my credit limit when considering whether to download something.”

It’s a subtle difference. Both can work, but option B is more needs-based and leaves a bit more room to explore solutions than option A. Option A implies a solution.

Next, take a hard look at each of these problems. Rank them. There are many ways to do this and none of them are perfect. I like to have teams vote for the “most interesting” problems. Why “interesting” and not something like “important” or “impactful”? Because people are motivated to work on things that they find interesting. It’s that simple. Most projects have peaks and valleys. Sometimes the project feels as if it’s flying along, and you are making great progress. Sometimes you are stuck in the valley of despair, and you just want to quit. An interesting problem can help push you through this valley. You may also use something like “Which problem are you most the most passionate about solving?” The problem that is really interesting or laden with passion is most likely to keep you and the team going when times get tough.

Now you have a ranking. The good news is that you can apply the same process to each problem in your roadmap. You’ve validated that the problem exists, and you’ve represented it with a problem statement. The next step is to approach each problem with the following tactics:

Ideate, Prototype, Test

Ideation will be focused because you know what problem you are trying to solve. Through prototyping and testing, you can quickly throw out or keep your ideas, refining along the way. After enough cycles (there’s no standard number, and you’ll know how many is enough) you will have a high degree of confidence in your solution.

At this point, you’ll have to think about the level of effort and any other dependencies that affect when this solution actually gets out to the world. This may impact the timing and the order in which things get built, which is OK. Just be sure to resist the temptation to jump to solutions for the other problems in your roadmap that haven’t gone through this process. It will be difficult, but worth it.

This quote, often attributed to Dwight Eisenhower, has given me some comfort when working with roadmaps. “Plans are useless, but planning is essential.”

Why go through this effort?

1. It gives your roadmap real meaning. It changes the debate. Instead of debating the solution, you will debate the problem.
2. It creates an emotional connection. People connect with problems. It’s human. Solutions are emotionless.

Consider these two examples.

“A solar-powered, self-cleaning toilet.”

“People in underdeveloped countries regularly become sick because their drinking water is polluted by their own sewage.”

Which one made you feel something? Which one made you want to act?

Here’s another key difference. A problem-based roadmap systematically addresses each problem by allowing for many possible solutions, each one validated along the way. A solution-based roadmap focuses on building out predefined solutions which might solve a problem but rarely allow for alternative solutions or validation until it’s too late. By allowing space for alternative solutions, you increase your chances of solving the problem. Solution-based roadmaps only leave room to try to solve that problem with that particular solution. But what if something else would work? What if there were a cheaper, better solution? You may never know.

If you’ve made it this far, you may be feeling conflicted. I’m guessing that you agree with much of what I’ve said in this article. At the same time, you feel like it must be wrong because no one really does roadmaps this way. I feel the same way. I have doubted myself many times and wanted to go back to the standard of solution-based roadmaps, but I’ve had just enough wins with problem-based roadmaps to keep me going. Be brave, go out and get your first win. I promise you won’t regret trying.