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

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.

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. 

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.

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!  

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. 

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.

As a general rule, everyone should have input into the product roadmap. In fact, at GitLab our mission is to make it so that everyone can contribute and we apply the same principle here.

A good product manager knows that listening to an idea, asking questions, and truly trying to understand it is in no way a commitment to implement it. So they don't shy away from this dialog, and in fact embrace it.

Now, when it comes to doing the prioritization, we need to be market driven and not stakeholder driven. Stakeholders are great for bringing you market insights. As much as we should strive to talk to customers, partners, analysts and prospects every day, there's only so many hours. Stakeholders can round out our understanding of what the market is telling us. It's easy when we all agree on a path forward. In practice, we will have disagreements. This is where it's critical to be transparent and explain why you're making the decisions you are. Having a transparent scoring criteria (see my answer to another question) is hugely helpful here. If your stakeholders can't show with market data why a decision you're making might be incorrect, they need to disagree and commit. If you're in a company where the PM isn't empowered to push back on stakeholders (with data), it might be time to look for another job.

Prioritizing is one of the hardest tasks for a PM. Balancing the needs of stakeholders, with customer needs, and business priorities. However, only your manager (and their manager and so forth) should have any "control" on your roadmap. Everyone else, should be able to provide In reality, you will find other stakeholders will expect some level of influence.

Once you've identified the initiatives for your team, you should use the RICE framework to prioritize them (see my other answer on this topic). This will give you a clear framework when discussing priorities with other stakeholders. For example, if sales is insistent that customers need a specific feature, you can show them that there are other features which have a higher RICE score. This may or may not always be effective, but it's a consistent approach that can be used with everyone.

There will be times that RICE scoring will not be enough. In these scenarios, it's important to hear out your partners and give them the opportunity to make their case.

This is possibly a good application of the RACI framework to determine which of your stakeholders have influence vs Control

• Responsible: Think of your product, engineering, and design leadership. They should have the same goals and priorities as you. Hence their feedback as well as endorsement is critical

• Accountable: These are your working partners, your engineering, product designer, content strategist. You want to create confidence with this group because they are responsible for delivering your roadmap. They can give you ideas on solving a problem or feedback on the feasibility of a solution.

• Consulted: This bucket is for teams and stakeholders that you engage with to create your roadmap. It could be Sales, Customer Success, Product Strategy, Voice of Customer etc. They definitely influence your roadmap but do not control it. Hence its critical to communicate your rubrik for prioritization and create a space for feedback.

• Informed: This group is everyone else who may be interested in learning about your roadmap

It varies. Mostly the stakeholders fall in four categories

1. Customers especially in B2B larger enterprise products (there is sometimes more control here)

2. Partners like engineering, design, data science etc. who provide feedback and help crystalize the sequencing of work

3. Senior leadership who often wants a concrete, confident and rationale driven roadmap but sometimes might also have top down asks

4. [Optional] For core, platform or internal products - Internal stakeholders like other product leaders, finance or HR partners etc.

   For control vs influence - my rule is I will pick my battles based on balancing ROI for company above ROI for product. In the longer term, this rationale helps guide better investment decisions. Sometimes, you do have to firmly disagree but commit to moving forward and sometimes it's okay to hold your ground respectfully but with rationale (it helps if you have already earned the respect of your leadership through your body of work within and/ or outside the company when making unpopular decisions).

At GitLab, we say that everyone can contribute. This is true even when it comes to input into the roadmap. Our product managers know that the best ideas can come from very unexpected places. Anyone can meet with us and give us their opinion or write up an issue and ask us to look over it. As far as real stakeholders go, customers, sales, product leadership, and executives have the most influence over the roadmap. Engineering, UX design/research, and security are also incredibly important to listen to, since they have insight that other groups often lack. However, the only one who actually controls the roadmap at GitLab is the product manager. Every product manager is expected to be able to synthesize multiple inputs from multiple sources, apply a prioritization framework, and manage the roadmap themselves. There are special circumstances, like security vulnerabilities or infrastructure issues, that will always take precedence, but that is all accounted for in the framework. GitLab has always been a product-led company, so everyone understands the role and authority of the PM in setting the course of their area of the platform.

I think that there are a couple of very important things to establish when setting expectations of influence vs. control.

1. The most important thing in allowing influence from stakeholders vs. direct control is that your company's policies support the PM as the directly responsible individual for the roadmap.

   • Company leadership needs to set the expectation that product owns the roadmap. If the product organization is not supported by company leadership as a whole, it is going to be very difficult for product managers to balance the expectations of influence over control. This is especially true in organizations where a specific group has historically had more influence in roadmap decisions. Sales or engineering heavy organizations that don't have explicit policies about product being fully in control of the roadmap will almost always run into the problem of someone else trying to control the roadmap. So, support from leadership is key to success in having a product-led roadmap.

2. The product organization needs to have transparent and explicit policies for how prioritization and roadmap decisions are made.

   • If other groups think that product is making decisions without a real plan, that will lead to distrust in the product org. Once trust is lost, other groups who believe that they have a better handle on what the company needs to succeed will try to exert control over the roadmap. The truth is that if there's no transparency about how product decisions are made and it seems like product is ignoring the real needs of the company's customers, who can blame them for trying to step up to make the company more successful?

   • Transparency with other groups needs to be a top priority if product managers want to gain trust. If they disagree with you, it gives them a chance to voice the reasons for their disagreement. When you have data that you can show them from your prioritization framework exercises to back up your decisions, you can show them why you believe your decision is correct. If, for example, sales is unhappy that the feature their top customer wants is not getting prioritized, you can show them the impact of the feature for the one customer vs. the feature you prioritized that has broad appeal to a lot of different customers, leading to greater (and less risky) recurring revenue.

When you have leadership support, have an explicit process for making decisions, and are transparent about that process, it is easier to maintain a culture of collaborative influence. As long as everyone involved is going towards the same goal of making the company successful and solving problems for your customers (i.e. there are no power struggles happening solely for sake of gaining power), you can balance the expectations of influence and control through mutual trust.

Your key stakeholders to shape a roadmap are:

1. Customers/Users: Capture direct feedback and use data to gain insights into user needs, pain points, and feature requests.

2. Sales & Marketing: This group will provide insights on market demand, competitive landscape, and feedback from prospects and customers.

3. Support & Customer Success: These teams are an excellent source for understanding common issues, pain points, and feature requests from existing customers.

4. Executive team: Seek guidance from the executive team to refine product strategy and align on business objectives.

5. Your product team: depending on the interconnectedness of your product strategy with other products, you will often need to align your team's roadmap with upstream and downstream dependencies with other teams in your organization.

6. Your core team: typically, UX, EM, and the engineering team will provide input on technical feasibility, resource constraints, and UX decisions that will influence a delivery timeline for new features.

How to balance influence vs control:

1. Ensure there is regular communication with the stakeholders that sets clear expectations. For example, sharing the roadmap with any of the groups above enables your stakeholders to provide input and be heard.

2. Use a prioritization framework such as MoSCoW or RICE to objectively evaluate features and weight their impact against technical feasibility.

3. Embrace regular feedback loops and take an iterative approach to deliver MVPs, validate assumptions, gather user insights, and refine features based on real-world usage and feedback.