Which stakeholders have input into your roadmap, and how to balance giving them influence vs control?

The stakeholders who typically have input into a roadmap can be:

1. Customers and Users:

2. Product Managers on other teams (that have a dependency)

3. Development Team

4. Executives and Leadership team

5. Sales, Customer Success, Support and Marketing Teams

Some tactics to balancing influence vs. control:

• Regular communication and feedback from all stakeholders

• Regular communication of the product vision, strategic goals and OKR's/metrics

• Sharing customer and end user usage data

• Defining clear roles and responsibilities (RACI) for each stakeholder to ensure their expertise is valued

Ongoing conversations to gather feedback on features will ensure a balance.

At Momentive there are several stakeholders that have input into our roadmap, a few main partners and collaborators are listed below:

• Other Product & Design Teams
• Sales/CS teams
• Marketing & Growth
• Research
• And more…

Most cross-functional partners just want to be heard and want to understand whether their requests will be addressed or not. This is why transparency is a key element in all 3 of the following tips to help you maintain the balance between influence and control:

1.  Give your cross-functional partners an acceptable avenue to advocate for customer requests and surface themes they are hearing from the market. We have a very specific process for capturing requests. All requests get routed through a feature request or feature feedback form that is centralized for our product team to analyze and address. We look at the data coming through those channels monthly and roll up the insights quarterly. The expectation is set that we will evaluate all requests but that there is no commitment to addressing any specific requests. An important aside is - As a product leader, be grateful for the feedback that you receive, there are many organizations that aren’t benefiting from the insights you are getting straight from the customer-facing teams.
2.  Help your cross-functional teams feel heard; be transparent about realistic outcomes they can expect. In all of the organizations I’ve had the privilege of working with, the friction between cross-functional product requests and roadmap prioritization was anchored on a misunderstanding of the product management function. Helping your cross-functional partners understand your process, their input’s role in it, and the outcomes that result should help alleviate some of the pressure to “just put it in the roadmap”.
3.  Close the loop - even internally. My team has a quarterly meeting with our cross-functional partners to give them an update on 1) the requests we’ve received, 2) which items have been delivered, 3) which items are in progress, 4) what our current expectations of delivery are, and 5) which ones we’ve recently received. We also address the items they have requested that we will not be delivering and do our best to explain why (e.g. not aligned to our current strategy, not a point of differentiation, we don’t have resource capacity for another large initiative right now, etc). This meeting alone has had an incredible impact on our ability to keep our team aligned with our cross-functional partners.

In my mind, several groups of stakeholders often influence the roadmap. They include your customers (both internal and external), your product team (e.g., engineering, design, data science), your internal non-product stakeholders (e.g., legal, compliance, sales) and your leadership. 

From these stakeholders, it's important to put most of your focus on the ideas coming from your customers and ideas generated by your team. While we all like to work on things that benefit the customer, it is equally important to make sure that your engineering team has the opportunity to work on technically challenging projects even if these things don't always directly benefit the customer. 

Then, there are times when your leadership would trump everything. Believe it or not, this doesn’t happen often. 

Prioritization is more art than science. My goal is to actively listen to all stakeholders and help communicate how I make tradeoffs and how that impacts timeline to deliver a requested feature.

But as a rule...

Customers have the most impact on roadmap.

Then engineering (especially on tech debt, architecture, compliance, and quality improvements needed).

Then, I weigh any influence from market trends and changing competitive landscapes. Here, I consult with analyst relations, product marketing, and competitive intelligence.

Then sales/CSM/support to learn trends/issues they're experiencing directly with customers or issues selling. 

And sometimes, executive input will trump everything else - but that doesn't happen as often as you'd think unless you work in very top-down work culture.

Ultimately, as the product manager, it is your job to make the final call on the roadmap prioritization. It is your primary responsibility!  

I appreciate this question! Generally speaking, we get inputs mostly from sales, customers and product/engineering. I’ve used the approach of building partnerships with stakeholders and that takes care of the influence vs control dilemma. When you have a strong partnership with your stakeholders, they trust you that you’ll make the right product decisions and in turn, you show that you value their inputs. So I would encourage you to think more about building stronger partnerships so you don’t have to struggle with influence and control.

It depends on the role and problem space, but I try to invite (1) virtually everyone I collaborate with on a regular basis, (2) their management/leadership, and (3) fellow PMs as partners in the roadmapping process. I think it's important to think of stakeholders more as partners in the roadmap creation process, since their ideas and input really shape my POV on what's important there.

Influence vs control is interesting. I've been in situations where stakeholders are pushing for specific features on the roadmap, which isn't necessary bad in itself - but it's important to (1) make sure it's clear *why* those things need inclusion, and (2) that if they are not included in a roadmap, you have a clear justification as to why. That could be for a lot of different reasons (eg. sequencing, technical effort, lack of certainty/understanding of impact, etc.) but it's important to clarify why you, as the PM, have decided to deprioritize thing A instead of thing B. A helpful tactic here to suggest influence without losing control is to propose an alternative placement for the given thing on the roadmap. For example, if it's risky to tackle thing A in Q1, don't just explain why, but also provide some rough guidance as to where thing A may end up as a result.

Lastly, I think word choice matters here, and commnunication tactics help. I've found success in "proposing" a roadmap, alternative prioritizations, alternative framing; giving stakeholders a deadline by which to provide feedback; expressing support for ideas even if they are not the most important ones at the moment.