Product Roadmap Best Practice – 6 things to avoid!

Best practices for product roadmaps is one of our favorite topics here at ProdPad. (This comes as a surprise to no one. We’ve built a whole software around it!)

Yet sometimes the best way to understand something is to look at what it’s not. So, on the other side of the coin, what are the worst roadmap practices that you should avoid?

Here are 6 of the most common faux pas that smart, well-intentioned product managers and larger product teams tend to make with their roadmaps.

1. Putting a timeline on the product roadmap

Focusing your roadmap around dates is a bad move. Often called a “timeline roadmap,” this method often results in planning way too far in advance. Your team commits to deadlines and loses the flexibility to iterate, change, and adapt. Of course, you must be able to adapt to situations – be that world events, market shifts, anything.

2. Too customer-driven

Absorbing customer feedback is a hallmark of good product management. But there is a limit. Being too driven by customer demands will turn your roadmap into a series of feature requests, and therefore a list of solutions that you’re going to build (see #4 and #5). As a product team, you become too reactive. Building small iterations or tinkering with features based on how customers wish they would work will eat up much of your time.

The other point to consider is who you’re reacting to. You might consider yourself customer-driven, but actually you’re listening to whoever speaks up the most. The squeakiest wheels are commandeering your product strategy and prioritizing your product roadmap.

If you’re doing that, you’re giving up the chance to take a step back and ask: What big problems could we be solving for the wider market, which our customers aren’t necessarily asking for now, but would solve their problems too and allow us to grow faster?”

Your customers don’t always know what they need, and they certainly don’t know the best strategic choice for your company.

3. Too data-driven

Yes, it is possible to be too data-driven, especially when it comes to excessive A/B testing. You’re trying to over optimize.

In my (perhaps controversial) opinion, A/B testing is just an expensive way to disagree. When you opt for an A/B test to give you an answer, that means you don’t have a real conviction either way. Both options would probably be okay. So instead of choosing one and learning from it, you build it twice. That’s twice the resources and money.

More often than not, you don’t end up with a statistically significant enough outcome to validate that option A is better than option B, or vice versa. To reach a reliable outcome, you either need a lot of users or a long time of testing. Neither of these really apply to small startups, when you’re just building traction or needing to move quickly. On the other hand, huge multinational corporations can afford to move slowly, and their small A/B tweaks can actually add up to $1 billion in annual revenue.

4. Prioritizing at the idea level

Poor prioritization is a downfall of many product teams, no matter how great your research, ideas, or backlog grooming. Like some of the other faux pas in this list, focusing on ideas (or features or solutions to build) means you’ll likely miss big opportunities and the real value you could be providing to your users. When you center your own ideas and then prioritize them, you’re basically taking an assumption and multiplying it by another assumption!

I also don’t recommend RICE or other weighted-scoring algorithms for this reason. Learn why these methods are problematic and which prioritization model could be best for your team.

5. The roadmap is a list of features

Let’s face it: a lot of product people think of their work as a way to keep the development team busy. As if development is waiting for work to do, and the product team is just filling the pipeline. But actually, PMs need to work with the wider team, think holistically about what else could be done, and generate experiments to solve larger problems.

By taking a step away from features and functions, you can think about product strategy from all angles. Does a new feature need to be built, or does the product need new positioning? Could we package or price the service differently, use different marketing copy on the homepage? 

6. Keep the product roadmap hidden

All too often, product teams make a roadmap and then keep it to themselves. There’s a misconception that it’s internal only, or that you must have one roadmap only. In fact, you can spin out multiple versions and share them accordingly!

The internal version contains all the minute details. This is so internal stakeholders can see not just the problems and why they need solving, but also how you’re going about solving them and what the outcomes were.

The executive version can leave out the nitty-gritty stuff, because executives don’t care or just shouldn’t hear about it. (That creates more questions and takes too long to explain!) Create a high-level version, perhaps showing multiple roadmaps in one space.

The customer version can simply show which problems you want to solve. It’s not a list of promises. Remember, you’ve removed the dates! Instead, the roadmap is a place to validate that you’re working on the right things – and customer feedback is excellent for this validation. If certain parts of the roadmap don’t resonate with customers, then you can probably deduce that it’s not important right now.