The best method for prioritizing feature requests = DON’T
Image credit: Matthias Mueller, Flickr
Why Product Managers should stop prioritizing feature requests
The best way for Product Managers to prioritize feature requests from stakeholders is a topic that comes up a lot. There are many different frameworks out there from feature request tree diagrams using good old fashioned post-it notes to the Kano model and buy a feature
techniques.
The best way for Product Managers 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 ton of manual, time-consuming processes. Now believe me, I know many of us Product Managers are superhuman but it’s very difficult for one person to make so many huge prioritization decisions on an ongoing and daily basis.
Sometimes others are involved; perhaps the heads of departments, the leadership team or customer focus groups but this can just add to the problem.
Here’s why:
Problem #1: Prioritization is being done by the few & not the majority
When you are building a SaaS product, there are a ton of stakeholders all with different demands on your product. For example:
Customers - You probably have a mix of customers. Small to large, strategic, bad fit, good fit, free triallers, customers in different locations and industries etc… All these factors influence what they need from your product.
Sales team - Desperate to close the next big deal, sales will always care about the feature requests that will help facilitate their success.
Engineering - There will always be engineering features that have to be taken into account. Customers may not see or care about these right now but believe me, they matter.
Customer Success / Account Management - Want a product that aids upsell and and allows their customers to reach their Desired Outcomes.
Support - Want the small, niggling features fixed
and off their plate so they can focus on real issues.
Leadership - Need to know feature requests are in the pipeline that aid growth and support the company’s strategic goals.
Everyday, product managers are expected to act as all of these people, making hard prioritization decisions about which feature requests are going to have the biggest impact.
This is an impossible task because you aren’t every stakeholder.
Problem #2: A Product Manager is not every stakeholder
So here’s the root of the issue. Product Managers are not, and cannot, ever be all of the product stakeholders. Sure, you can understand your their point of view, goals and objectives but you can never see things exactly how they do. And you certainly can’t predict or understand how & why people change their priorities so frequently.
And there isn’t just one salesperson, Customer Success Manager or a single strategic customer. There are lots of individuals that make up these moving pieces, each with their own changing thoughts and opinions on your product.
Problem #3: The data is often stale and incomplete
Collecting data using a standard prioritization technique can result in Product Managers working with a heap of stale and incomplete data. Running 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 learn, have new experiences and change what they need so it’s important to capture this.
Customers also have evolving requirements as they get to grips with your product. Early feature requests
from a new cohort of users can often be as a result of lack of understand about how a piece of existing functionality works or a gap in your help and support documentation. This can lead to a lot of feature requests needlessly appearing at the end of your product backlog.
How we solved this
All of this led us to taking manual prioritization on behalf of others away from Product Managers. Note that we took away the manual process and ongoing prioritization and NOT the decision-making or need to engage others in regular product discussion.
Requirements and feature requests are gathered ongoing from all of our customers and internal teams. This data is then automatically split out (segmented) so we can get true visibility of what matters to who and why. Some examples of the data we look at includes:
- What’s important to each internal team (e.g., sales, customer success,engineering etc…)
- How demands of big customers compare to small
- What key, strategic clients & prospects are asking for
- Which features will have the highest impact (we map feature value against dev effort)
- Overall account priorities & the requirements of the individuals within an account
- Top requests for each section of our product (for example, UI, backend, user engagement)
When SHOULD a Product Manager prioritize feature requests?
Gathering and segmenting our feature request data allows us to be confident we are working with relevant and up-to-date information. Product discussions now take a fraction of the time and we are completely freed up from the old data gathering and prioritization techniques.
Capturing priorities of stakeholders ongoing allows our product team to focus on prioritization where it really counts by:
- Defining and agreeing product strategy with the leadership team within the understanding & framework of the company objectives; and
- Prioritizing what goes on our product roadmap using the data collected. The product and company strategy is the key reference point.
In summary, Product Managers now work a whole level above the capture and prioritization of feature requests from stakeholders. They are freed up to make strategic and data-driven product decisions instead of spending hours on laborious manual tasks which only ever resulted in imperfect information.
No more playing with spreadsheets, counting feature votes and desperately trying to get that call with a strategic prospect ahead of a prioritization session. Surely that leaves us with more time for a cuppa…or maybe not… ;)
Check out our other resources on prioritization to learn more.
