How I Get Buy-In on My Product Roadmap

You think the hard work of developing a product roadmap is done when you’ve done extensive research and analysis, completed interviews, and determined what your company should be building. Alas, this is not the case. The hardest part is often getting everyone in the company on board.Here are some approaches I’ve used over the years to gain alignment on the roadmap.

1. Have goals.

It helps to have company goals that the roadmap can fit into neatly and that all your stakeholders enthusiastically support. (Admittedly, that’s only been the case for me a couple of times in my career) If your company doesn’t have specific goals, come up with some and check that the execs agree. Note - even with company goals, you will still need to convince everyone that these specific roadmap items are the “best” things to work on to achieve them.

2. Remember that your colleagues are also your customers.

Remember you are also the product manager for your internal teams — they are your customers as well as your “teammates.” It is likely these teams depend on the right product being developed so that they can hit their goals and get rewarded. They may also want product changes to help them do their job better or easier, cut costs, help close deals, reduce churn, reduce tech debt, and improve usability. Their requests may not map exactly to the company goals — you’ll certainly have to employ the word “no” from time to time — but it’s important to consider their needs and make sure they feel heard. Take time to share where their personal requests fit in the priority list and why certain other items are above their asks. Do your best to work in some of their requests, even if it is just the little ones, to keep them going until you can get to their bigger needs.Even if you could dictate the roadmap without the rest of the company agreeing, this approach wouldn’t pan out well. It’s your job to sell the roadmap to the team so that everyone gets behind it and does their best work to deliver. When I approach other teams, it helps me to imagine that each group could set the roadmap on their own and it’s my job to get them excited about the things that I’ve identified. I can only do that if I really believe in the roadmap myself and have good reasoning to back it up.

3. Help stakeholders get into your frame of mind.

As you’ve learned by now, being a product manager means saying ‘no’ to a lot of things and carefully using your limited development staff. But your colleagues haven’t necessarily experienced that and also don’t have insight into all the feature requests you have had to consider. I’ve often started roadmap discussions by listing “all the things” to help provide some perspective. It helps to present this in a visual way. For example, you may want to use a “word cloud” of all the feature requests you know are popular among your stakeholders, then cover up some part of it to represent the percentage you can likely deliver.Talk about the criteria you used to evaluate the ideas — e.g., their fit with company goals, number of customer requests, churn and win/loss data, market size, cost savings, and effort level. Make sure to do this research on a large number of ideas, especially ones you know are hot topics internally, so that you can show how they do or do not meet the criteria for getting done.Don’t forget to describe what each item is. If all you have is a feature name, everyone will have different assumptions about what that is.

4. Involve knowledgeable team members along the way.

Many people in your company are very smart and know your customers and market well. Make sure to involve them, especially when validating the data and assumptions you are making about the potential items on the roadmap. Share the results you’ve discovered after analyzing the ideas against your criteria. Getting buy-in on the final version of a roadmap is much easier if stakeholders have been involved along the way.

5. Use Roadmap Dates Wisely.

No discussion of a roadmap is complete without dates. We are typically hesitant to give dates, and for good reason - dates can put unneeded pressure on development teams, reduce our flexibility to adapt if something comes up, and if dates are missed, it can lead to a lack of trust. But, to be reasonable, we do have to let people know if a new feature will be delivered in a matter of days vs. years. Do your best.Personally, I usually have luck anticipating what we will have ready in the next quarter and the one after, but then it gets a bit fuzzier. At that point, I can have a good idea about the next half year, followed by a vision for the following year, which will likely change.

6. Hold Yourself Accountable.

Finally, it’s key to measure success against your criteria, show progress, and hold yourself accountable. Next time you go to get buy-in on a roadmap, it will be much easier if you can demonstrate the success of the last roadmap and any lessons learned that will be applied this time around.