This is how product managers should prioritize feature requests from stakeholders

A topic that comes up in many conversations I have with product leaders is how product managers (PMs) should prioritize feature requests from stakeholders. Even though there are plenty of different frameworks out there—from feature request tree diagrams with post-it notes to the Kano model and “buy a feature” techniques—the best way for PMs to prioritize stakeholder feature requests is not to do it at all.

Let me explain.

Many of these techniques rely on a single person and a lot of manual, time-consuming processes. I know a lot of product managers are superhuman, but it’s very difficult for one person to make so many large prioritization decisions on a daily basis. Even when other people are involved (e.g. the heads of other departments or members of the leadership team), it can just add to the problem.

Here’s why:

Problem #1: Each stakeholder has their own needs

When you’re building a SaaS product, there are multiple stakeholders with their own unique demands of your product. For example:

• • • Customers: You probably have a mix of customers—small and large, B2B/B2C/hybrids, free trial users, customers in different locations and industries, etc. All of these factors influence what each customer needs from your product.
    • Sales team: Focused on closing the next big deal, sales teams tend to care about the feature requests and functionality that will help facilitate their success.
    • Engineering: There will always be engineering resources and limitations that have to be taken into account, often behind the scenes.
    • Customer success/account management: These teams want a product that aids upsell efforts and enables their customers to reach their desired outcomes.
    • Support: Your customer support organization might care the most about the small feature fixes they hear in support calls and tickets.
    • Leadership: The leadership team needs to know how the product roadmap supports the company’s strategic goals.

When product managers are expected to act as all of these people, it’s difficult to determine which feature requests and product decisions are going to have the biggest impact.

Problem #2: A product manager is not every stakeholder

Product managers are not (and cannot ever be) all of the product stakeholders. You can understand their point of view, goals, and objectives, but you can never see things exactly as they do. And you certainly can’t predict or understand how and why people change their priorities.

Not to mention there isn’t just one salesperson, customer success manager, or a single strategic customer. There are a lot of individuals who make up these groups, each with their own thoughts and opinions about the product.

Problem #3: The data is often stale and incomplete

Collecting data using a standard prioritization technique can result in PMs working with a heap of stale and incomplete data. User workshops are great, but they don’t capture how stakeholder priorities change over time, so feature prioritization sessions are often run on imperfect and out-of-date information.

Problem #4: Priorities change frequently

Stakeholders continuously learn and experience new things, which can alter what they need from your product. While you can’t control how their needs shift, it’s important to capture as much information as possible (e.g. using in-app surveys or system for collecting customer feedback). Customers’ needs will also evolve as they get more acquainted with and proficient in your application. Early feature requests from a new cohort of users can often be the result of insufficient onboarding or a gap in your help documentation.

Lean on data to help with prioritization

Since product managers still need to consider stakeholders’ needs when making decisions, it’s important to remove the manual element of prioritization, but keep the collaborative spirit of including inputs from customers and other teams. The best way to accomplish this? Leverage the data available to you.

The first step is to set up a way to automatically gather requirements and feature requests from customers and internal teams on an ongoing basis. Then, you can segment data to better understand what matters to who (and why). Here are some ways to segment your data:

• • • What’s important to each internal team 
    • How demands from large customers compare to those from small customers
    • What features strategic customers and prospects are asking for
    • Which features will have the largest impact (map feature value against development effort)
    • Priorities and requirements at the account and user level
    • Top requests for each area of the product

This way, you can be confident that you’re working with relevant and up-to-date information, which helps drive efficiency in the decision-making process. No more playing with spreadsheets, counting feature votes, and desperately trying to get that call with a strategic prospect ahead of a prioritization session. 

Capturing customer feedback and internal requests on an ongoing basis allows product managers to make strategic and data-driven decisions instead of wasting time on manual tasks that often result in imperfect information. Teams can define and agree on a product strategy with the leadership team that supports overall company objectives, and prioritize roadmap items based on data rather than gut instinct.