Product roadmaps can fail — here’s how to prevent it

Product roadmaps are an invaluable tool – not only for product managers, but every stakeholder involved in bringing a product to market. They are a statement of intent, providing clarity around your product plan and guiding you toward your product vision. Without one, your organization may find itself on the wrong path.

That said, building a product roadmap is full of challenges. In a recent fireside chat, Productboard’s Scott Baldwin was joined by product leaders Joshua Childs (Validity), Kristin Lundin (TapClicks), and Adam Krbušek (GoodData) to discuss the challenges they’ve experienced when building a product roadmap – and how to overcome them.

Below is a lightly edited version of the conversation, which you can also view on-demand.

SB: What are the most common challenges you see product teams face when building roadmaps?

JC: One thing that comes to mind is the pressure to orient a roadmap towards the loudest or most prominent voice you’re hearing. 

It could be that some of the core days you’re working on your roadmap coincide with the days where you’re putting out a particular fire. You go back to your desk or team meeting with the strong sense that you need to do something about X, Y, or Z. There’s a tendency to put that on the roadmap right now. That’s known as vividness bias. 

We’re all human, but it helps to take a step back and remember all the other things you need to be balancing.

AK: It’s easy to be overly optimistic and commit yourself to too many things on the roadmap, even though you won’t be able to meet those expectations. It’s important at the beginning to set the scope and make sure the team is synced. Everyone should be aligned with your team to set the right expectations. 

One of the greatest challenges I encounter is the number of voices and requests. Everyone has an idea that they want to be on the roadmap. It’s important to listen carefully because PMs are not all-knowing wizards with a crystal ball. We are facilitators. But at the same time, you need to focus on the direction you are taking, so you don’t create a feature soup that will lead you nowhere. 

“It’s very easy to focus on solutions and not problems. Everyone wants to build something new and shiny – it’s the little child inside of us. But as product managers, our goal is to focus on customers – to build something that will be helpful for them.” 

KL: One of the biggest challenges is balancing all those voices. You have the voice of your executives, saying if you build this it’ll help you get funded. Then you have customer success people and whatever is hot on their minds. Also, you’ve got to understand what your competitors are doing. 

So the challenge is not only balancing the different voices. It’s also about how you stay strategic while keeping your CX team from biting your head off because they’ve got a couple of enterprise customers who are going to churn if they can’t use your product the way they need to.

SB: With many teams wanting a say in your roadmap, how do you keep everyone happy while maintaining control over its direction? 

AK: Building a roadmap isn’t a one-person job. It’s a group effort – or at least it should be. But the PM or product team should ultimately be responsible for making those decisions. I think it’s a combination of collaboration and ownership. If stakeholders are included in the decision-making, they feel that their voices are heard – and that’s a huge part of getting buy-in.

Building a roadmap is not a goal. It’s a continuous activity where you evaluate, iterate, and do discovery and delivery. You have a strategic direction, and that’s what you follow. It’s important to communicate what your direction is. If everyone is happy with the direction, they won’t focus on those small details they want. 

I try to never commit to anything until the roadmap is built. Because that would limit me. So I always try to set the direction, and then after that, I try to communicate it with everyone. Not everyone will be happy – that’s something we have to admit.

KL: We use OKRs to guide what our issues are for upcoming quarters. One of the advantages is that it raises the visibility level across the organization as to where certain teams are focused. OKRs help drive everybody toward that focus.

We do a lot of product analysis, but we also supplement that with some key strategy meetings with our customer-facing teams. Every couple of weeks or so, we meet with our CX team and go through a punch list from their perspective. This allows us to head off escalations. CX can raise something the first time they hear it, rather than two months later when the customer is upset. 

Lastly, we always keep some slots on our roadmap for customer demands. We’re an enterprise software company that sells a marketing operations platform. We serve large media companies and agencies, and they can be pretty demanding. So we have some blocks of time that are dedicated to them.

JC: I think you can fall into the trap of assuming that the person that’s coming to you with their ask has spent a lot of time thinking about it. 

Again, everybody experiences vividness bias, everybody’s coming from a customer call that motivates them in a specific direction. Sometimes, that’s where those asks are coming from. So it can be very valuable to pull the conversation back and ask them a few questions about what they’re trying to get. Ask them how it ties into your broader company initiatives. 

“Be an ambassador for the company’s goals. OKRs are a good way to put that on paper and organize people around them. Ask people how their ask is aligned with their OKR. They may not walk away happy, but at least they’ll gain a different understanding of what they need to be pushing for in their particular functional role.”

SB: What are the advantages of having a successful product roadmap and strategy? How does that set you up for success?

KL: If you want to get from Boston to Austin, you need to know to take routes 95, 85, and 20. Having a successful roadmap will help you get at least close to where you are aiming to go.

Say your company is heading toward $10 million, $100 million, or whatever. Having a roadmap that shows how you’re going to accomplish that goal, what your customer base is going to look like, and how you are going to build that out – in my opinion, that’s the only way you have a dream of getting there. 

“There’s nothing better than a team that’s all pulling in the same direction, when everybody’s aimed at the same goal, working together to try to get there. A roadmap is a great way of getting people in that groove and aligned on what you’re doing.”

It’s hard work to get the roadmap and the strategy done. But once you have it and can start to see the benefits of it, there’s nothing better. When you get sidelined by an executive who walks in and says, “I’ve got this great project we need to do.” You can head that off and say, “How does that get us to that $10 million target?”

JC: There’s just no better tool for discussing opportunity costs than to say, “Here’s the plan that we had. This is what we need as a business. What is the opportunity cost of knocking one of these things off of our roadmap to do something else?”

One thing I learned coming up through startups is that plans are worthless but planning is invaluable. Things change so rapidly. It’s tempting to just respond. But forcing yourself to do that planning, to try to figure out what your roadmap is going to look like, can help you gauge the health of your product discovery and development process.

AK: I think it’s important to realize what your product strategy is. It’s a high-level plan that tells you how to achieve your product vision. And the product roadmap I see as the execution of that product strategy. So if you want to execute a strategy, you need to build a roadmap.

If you have a good roadmap, developers will understand how the parts of the product they are working on contribute to that strategic goal. Your marketing and sales teams will be able to articulate examples of the product’s benefits and unique selling points.

 “What would happen if a company didn’t have a product strategy or roadmap? I think they would still deliver some features, but they would never contribute to a higher goal. They would never go in the same direction. It would be chaotic.”

SB: Tell me about a success story you’ve had where your roadmap helped align your team or organization around a particular product direction. 

JC: We had some declining revenue when I first took over a product I was working on. We worked hard and got the top-line revenue back moving in the right direction. As we were doing that, there was a particular segment of the audience for whom the revenue was declining. 

At some point, the executive came to me and wanted to know why that revenue was declining and what we could do to stop it. After lots of financial analysis and data digging, I was able to come back and say, “This is why this is happening, and this is the roadmap we have for it over the next year. And the reason the roadmap looks this way is because of the things that you’re now seeing.” 

In other words, I was able to demonstrate that the roadmap had anticipated what we needed to do with that section of the product. And we were able to avoid having this conversation where it’s basically me spitballing versus the executive’s spitballing about the problem and how to fix it.

If I hadn’t had that in place to show that I’d been thinking about it, it would have been a much tougher conversation to get through – and we may not have ended up doing the things we needed to do.

AK: My success story was triggered by the changing landscape of user behavior and technology. At GoodData, which was founded 15 years ago, we had some concepts and products that were built over the years. But during that time, public clouds became a thing and more consumerism started penetrating the buying journeys of enterprise customers.

All these factors collided, meaning we had to find a new strategic direction. So at the end of last year, our management decided we needed to build a new product that would address all these changes.

We started by defining our target persona and the problems we would solve for them. Because it was still very abstract and people in the company didn’t know what to make of it, we started to shape it into the form of a roadmap.

We outlined what we would do for our customers, our main objectives, and even the milestones we would deliver. This gave us alignment. Suddenly, all those DevOps teams weren’t afraid anymore. They saw it as a challenge. The marketing team started having brainstorming sessions because they understood what they would be selling. Our sales team had materials that they could start to prepare. 

KL: A few years back, our underlying infrastructure needed updating. It was very much engineering-driven, and it wasn’t going to result in a lot of fancy new stuff for the customer.

It would have been very difficult to drop that on the roadmap and say, “Hey, we’re not going to do anything else for the next three months because we’re doing this infrastructure project.” So we broke it into smaller pieces and fed it into the roadmap over time. It stretched out the project a little bit longer, but we were able to make incremental progress. 

We were able to do that because we had a roadmap we could plug it into and show not only that we were making progress toward the infrastructure goal, but that we were also iterating with our CX team on the product.

Without a good roadmap, we would either have risked a whole pile of churn because we would have pulled ourselves out of doing any feature work, or we would have just held off the infrastructure work until it was at the point where we couldn’t extend our platform anymore. 

SB: How would you describe the differences between customer-driven and product-led roadmaps?

AK: Every product team should talk to customers and do some discovery work. They should know who they are building for and what their needs and problems are. Where I see the difference is where the development of the product originates. 

In a customer-driven business, the development of the product roadmap and its direction originates from outside the business, from the customers. With a product-driven business, the development of the product originates from an internal vision and strategy.

I think we should be somewhere in the middle. We should talk to customers and take care of them, but there should be some balance. We should be moving in the direction of the vision we have. Otherwise, we will stagnate.

KL: Ultimately, if your roadmap is not customer-driven, maybe you need to think about what your business is doing. You may have a roadmap for something that isn’t intended to grow a business. But for most product managers, we’re here to build businesses and grow user bases.

The best roadmaps I’ve seen are the ones that balance the qualitative and the quantitative. Maybe you’re analyzing your user traffic, and you’re doing your due diligence around that to find out what people are using and what they’re not using. At the same time, you’re also having some qualitative conversations with customers to understand the problems you could be solving for them.

“If you’re doing a good job, you’re balancing both the qualitative and the quantitative. You’re using both to influence your decision-making and your recommendations. That’s how you build a solid, high-quality roadmap that hits everybody’s needs.” 

JC: I would make a distinction between customer-driven and customer-informed. When I think of customer-driven, I think of roadmaps that try to avoid tension. They’re susceptible to skewing towards the loudest and largest customers. You’re trying to ease tension and calm the waters.

They can also carry the risk of not being aligned with your product vision. You might be trying to find product-market fit, and one day you wake up and realize that half the customers you’ve been listening to are not the customers that your vision calls for. So you have to make some hard calls about whether you’re going to stick with your vision or whether you’re going to keep those customers happy.

“Customers have no obligation to your product vision. They have no obligation to your business vision or strategy. They have their needs and their wants, and they’re going to let you know what they are. So, for me, a product-led roadmap needs to have the component of being customer-informed.”

A product-led roadmap isn’t built to ease the tension, but to balance the tension between all the stakeholders. That means empathy for the customers and a responsibility to the business. You have to strike that balance.

SB: I’d love to hear about your experiences of how a product management platform has helped you build and communicate your roadmap, in comparison with classic tools such as PowerPoint or Excel.

JC: Everyone’s situation is different in terms of the size of the organization, etc., but in most cases, there are just too many streams of feedback to keep track of in something like Excel. 

And unless you’re using a tool that’s purpose-built for this kind of thing, it’s really hard to understand the quantitative side of the feedback you’re getting – not just what the issue or request is, but how many people have come to you asking for that.

“Having a system of record frees up a lot of time to make more clear-headed decisions. It allows me to defeat things like vividness bias and come back to a place of perspective around what’s going to guide my decision-making on any given day.”

AK: Before I started using a project management platform, I didn’t know I needed one. Now, I can’t imagine life without it. One reason is having that single source of information. 

As a product manager, I receive information through so many different channels – whether it’s Slack, my customer-facing colleagues, support tickets, or user research interviews. Now, I have a single place where I can bring all these insights together and categorize them.

I can then use that information to help me build a roadmap. If I have OKRs, and I have a clear vision, I need to prioritize it all somehow. I like to use the RICE scoring methodology, and now I can sort everything based on those criteria.

Also, there’s no need to build different roadmaps for different stakeholders. I can just display different pieces of information and hide other parts, but there is one master roadmap behind it all. It’s very easy to manage.

KL: One pain point we had was when we got feedback through a variety of channels, it would be passed through several people. By the time it got to the product team, it would often look different from the original version. 

What’s great about Productboard is the ability for our end customers to be able to create their own feature cards or requests and also vote on things we’ve already curated. There’s nothing more powerful than being able to look at a feature and say, “I’ve got 150 customers who all say that this is incredibly important for them.”

See more from our webinar series highlighting best practices in product management.