All related (7)
Marc Abraham
Senior Group Product Manager, IntercomJune 21

To get roadmap approval from internal stakeholders, we need to make sure that they're bought into the overarching product vision and strategy first. This means explaining and getting input into the direction for the product and the path we're taking to achieve the vision. It thus become easier to get approval for roadmap goals and sequencing from stakeholders, as they should logically follow the vision and strategy. 

One thing to align with stakeholders on is the expected format of your product roadmap. A roadmap is a communication tool and it's therefore important to be clear on what your stakeholders expect to learn or do with the information provided through a roadmap. For example: What is the expected level of detail of roadmap items? Timings? Etc.

Andrew Clark
VP of Product, 15FiveJune 9

I flinched at the word "approval" here.

I don't like the idea that Product would be seeking roadmap approval from other departments in the org.

What you really want is buy-in. You want your key stakeholders to be as confident and excited about the roadmap as you are. 

Here's how to make that happen:

1) Provide channel(s) for continuous input and take that input seriously. Stakeholders will make sure their teams to provide good input so long as they see how that input influences the roadmap. You may have to connect the dots for them.

2) Over-communicate roadmap strategy and the why behind it. Do this all the time. Product priority can often seem random to others in the org, regular reminders about what you're aiming at can help.

3) Shop the roadmap around to key stakeholders on an individual basis, and speak their language when you do it. This is typically a quarterly exercise, done before decisions are final. You want it to be clear that they have genuine influence during this stage, but you/team are still making the final decisions. Speaking their language means talking about things they care about—most don't care too much about your prioritization process/formula/etc, they just want to know how what you're doing will impact their team's success and the business overall. Usually in that order. : )

4) Build trust by delivering on your claims. This one can be tricky! When you get good at estimating impact, you can go back to your stakeholders and say "See? The process works." Depending on your team's maturity, this may be broad and somewhat vague or very specific to the direct impact your releases had. You want to always move toward the latter.

If you can do those things consistently, you won't be asking stakeholders for approval, you'll be regularly collaborating with them on the best way to move the product and the business forward.

Tracy Montour
Head of Product Marketing, HiredScoreJuly 29

Get alignment early and often. Stakeholders should not be surprised by anything on the roadmap when they see the proposed draft. Outline which stakeholders you need to influence, get their inputs, incorporate them where necessary, and show them you're strategically moving the roadmap forward. There will always be pushback and inputs at every stage of the roamdap process but your life will be a lot easier with this approach because stakeholders will feel they were part of the process. 

Andrew Clark
VP of Product, 15Five
Yes and no. I think of these relationships in terms layers of depth. Design and Engineering are, of course, your deepest stakeholder relationships. You're building a product together, so the dynamic is fundamentally different. Customer Success (and Support) should be the next layer. They should generally have a better understanding of the product than your go-to-market stakehodlers, and the time they spend with customers usually leads to more specific insights. This relationship can and should be more collaborative than the next layer. Sales and Marketing are the next layer, as the...
Julian Dunn
Senior Director of Product Management, GitHub
First, if you truly have stakeholders whose goals are 180 degrees opposite from yours, that's an alignment problem in the organization's executive leadership team and you have to decide whether that's something you believe you can change. But in my experience it's rarely this clear cut. Nobody has a product team that's trying to increase revenue only to have a sales team that's trying to minimize revenue, for example. More often than not it boils down to a conflict between things that appear mutually exclusive but aren't. Take, for example, the common conflict between PM & engineering on...
Guy Levit
Sr. Director of Product Management, Meta
I love this question! It happens a lot and working through it is part of our role as PMs. There are a few layers to my approach here: First, start with building the relationship. (I hope this theme is clear by now ;-). While your goals may conflict, at a higher level you are playing for the same team, and having constructive, trusting relationships is a key for any team’s success. You don’t need to agree, but at least seek to understand and show empathy. Second, focus on higher level framing, rather than your own goals - You both want the company to succeed, and if you start double cl...
Marc Abraham
Senior Group Product Manager, Intercom
I measure the success in my role based on the measurable value that my team and I deliver to customers, which in turns translates into business results. Example metrics are (increasing) conversion rate or (reducing) response time to end-users. I wouldn't say the KPIs themselves have evolved dramatically. The leading and lagging indicators that I've been accountable for thus far have varied based on the products (e.g. B2B vs B2C metrics). As I've grown within my role, I've become accountable for a portfolio of products, as opposed to the success metrics for a single product.