How to Prioritize Feature Requests and Build a Product Your Customers Actually Want

Use customer feedback to develop your product the right way

Have a massive list of feature requests from your customers? Prioritize the most important features using this system. Photo by RonaldCandonga from Pixabay

You’ve built a solid system for tracking customer feedback and feature requests. And it’s working.

It’s working so well that you now have a list of 400 features that your customers want you to build.

Which ones do you pick?

Your decision matters. Do it right and you’ll delight your customers, improve retention, and boost conversions. Do it wrong and you’ll waste money and your development team’s time building a product that doesn’t have a market.

In fact, the number one reason that startups fail is that they build a product that no one wants. And product/market fit is just as essential for established companies as it is for startups.

Prioritizing the right features is critical, but it’s also difficult to do. In hundreds of conversations with product leaders, I consistently hear that this is where much of the art and the science of building a great product lies: in figuring out what to build — and what to build next.

Adding to the confusion are the many, many “methods” for prioritization out there, including the RICE method, the Kano method, and many others. But somehow very few — if any — of these methods actually tie your prioritization directly to what your customers have told you they want.

So I want to fill that gap.

In this article, you’re going to learn how to prioritize feature requests using the qualitative customer feedback and feature requests you collect.

First, I’ll go through the prerequisites — what you need to have in place if you’re going to create a robust prioritization system. Then, I’ll outline a five-step process that represents our own tried-and-true method for prioritizing feature requests, including the most useful prioritization factors to use.

The prerequisites — get yourself set up with a solid customer feedback tracking system

Before you can prioritize your customer feature requests, you need to actually collect them. A robust and useful feedback collection system should have at least the following characteristics.

It collects all relevant feedback

Making the right product decisions means collecting all the relevant data.

That means collecting not just the feedback that goes directly to your product manager from a survey, but collecting it from each of your customer-facing teams.

A solid system will pipe in data and feature requests from sales, support, customer success, and any other teams that talk directly to your customers.

It needs to synthesize customer feedback into a single, centralized database

Your feedback and feature requests are your data. To analyze those data, you need to put them together in a single place.

That means taking them from the multiple sources you receive them in — Intercom, Slack, Help Scout, your churn reasons, NPS results, email, and so on — and bring them together.

It needs to segment the requests by relevant customer attributes

To draw useful insights, your system needs to be able to segment your feature requests based on relevant customer attributes. This lets you know who wants what.

That means you need to be able to collect or add key meta-data that matters to your business.

Relevant attributes could include stages in the customer life cycle (prospect, free trial, full customer, churned), customer plan (free, small business, enterprise), the value of the client’s monthly recurring revenue (MRR), and so on.

It needs to build in feedback from your internal stakeholders

It takes a village to raise a product.

Meeting regularly with internal stakeholders to check your data and get on the same page with product decisions is essential.

How to prioritize feature requests using customer feedback

Prioritize feature requests so you know what to build first. Photo by meneya from Pixabay.

So you’ve met the prerequisites and you’ve got all your data… now comes the hard part: using it to determine what to build.

There are lots of ways to do this, but here’s the process that we like best.

• Step 1: Get clear on your business goals
• Step 2: Filter the feature requests based on what your most important customers want
• Step 3: Prioritize further by other attributes that matter
• Step 4: Determine your development budget
• Step 5: Choose the features and confirm with other stakeholders

Step 1: Get clear on your business goals

You build software to accomplish your business goals. It’s hard to know what to build if you don’t know what you’re trying to accomplish. Defining and focusing your goal is the first step.

Possible business goals could be:

• Increase traffic to your website and exposure to your digital presence
• Increase free trial sign-ups
• Increase conversions to paying plans
• Increase subscriptions to the enterprise plan
• Increase retention and reduce churn

Now, obviously, most businesses will want to accomplish all of these — and more. But for the sake of focus, you’ll want to choose a single one. In many cases, your executive team should have already done this and specified clear objectives that will drive your decisions.

Figuring out what your most important goal is will help you decide which feedback you should be listening to the most and ultimately what features you should build.

Step 2: Filter the feature requests based on what your most important customers want

Now you want to figure out how to cut through your massive list of possible features and come up with a “shortlist”.

There are many different ways to rank a stack of features to determine priority. But a critical piece of that process is determining what features your most important customers want.

Who are your most important customers?

That depends on the business goals you’ve specified. If you’re trying to get reduce churn, you probably want to prioritize feedback from churned customers and your at-risk accounts. If you’re trying to boost sales, it makes sense to prioritize feedback from prospects.

There are a ton of different dimensions you could use to prioritize features based on which customer asked for it. Here are some of them.

Segment by customer value.

Here, you would rank requests from your most valuable customers the highest. You would do this by prioritizing and scoring your feedback based on some sort of value metric.

Examples could include:

• MRR
• Product plan level
• Some other kind of value. Perhaps they’re a key partner or fit your ideal customer profile (ICP)

Segmenting this way is a great option if you want to increase the retention of your most valuable customers.

One way to filter your feature requests is by customer plan. Screenshot of Savio dashboard by author.

Segment by life cycle stage

Here, you’re ranking or scoring your requests based on what stage of the lifecycle your customers are in.

You would do this by prioritizing feedback from customers at a particular life cycle stage: free trial users, paying customers, churned customers, and so on.

This is a great option if, for instance, you’re looking to improve the experience of existing customers to reduce churn.

Segmenting feature requests by customer life cycle can also be valuable. Screenshot of Savio by Author

Segment by vertical

Here, you’re scoring requests based on the vertical of your customers.

For example, you might prioritize requests from customers in the hospitality industry more highly, or real estate agents, or you might prioritize SaaS companies.

This is a great option if you’re trying to expand into a new market or target customers that have a particular set of needs in common.

Prioritize by key accounts

Here, you might identify and prioritize feedback from customers who are special to you in some way. They may be your biggest customers or they may be a customer who has been with you since your company started.

Prioritizing the requests of these key customers is particularly useful to build relationships and increase the retention of these clients.

Prioritize by the sheer number of requests

This is the simplest way to prioritize: simply look at the number of customers that want a feature. You could give the features that have been requested by the most customers the highest priority.

This is an easy way to prioritize, but it’s also limited. It won’t necessarily tell you what you want to know.

For example, 80% of your requests might come from your free subscribers. That’s great, but they may not want the same features that your enterprise customers want. It might be more important to you to keep your enterprise customers happy — after all, they’re paying your bills.

You’ll be able to make better product decisions if you dig a bit deeper into your feature requests and look beyond simply how many customers want a particular feature.

Segment your customers by attributes so you can know what your most important customers want. Image created by author.

Step 3: Prioritize further by other attributes that matter

Now you have a kind of shortlist of the features that your most important customers are asking for.

If you’re lucky, that first pass will give you a tidy list of features that you can give straight to your development team. But often that “shortlist” is still pretty long. You might need to continue to whittle it down.

Here are some further factors that you can use to prioritize your feature requests:

Recency

Things change over time — your target customers, your product, and even the market. Often recent feedback is more useful than older feedback.

Knowing that, you may choose to prioritize your most recent feedback. Or, you may choose to prioritize those requests made in the past 30 days.

One way to find the most relevant feedback is by prioritizing more recent feedback. Ideally, you’ll collect your feedback in a way that lets you filter it by date. Screenshot by author.

Strategic Alignment

You’re not just building your product for today’s market, you’re building it for the future market.

Sometimes you may choose to build things that are strategic even if they’re not necessarily in alignment with your feedback.

Remember, though, that this kind of decision probably isn’t best taken lightly. If you’re choosing to build something in the absence of feedback — or that even goes against what your feedback data says — make sure that is a well-considered and intentional choice.

Bang for your buck

Finally, some features are easier to build than others. Some may be really low hanging fruit.

Your dev team can give you a high-level sense of how much time a feature will take. Use this to help you understand the “cost” of each feature. When two features are otherwise just as high priority, it probably makes sense to build the easiest ones first.

Look for — and prioritize — the quick wins: those high priority and low effort features.

Your high priority, low effort features are good candidates for prioritization. Screenshot by author.

Step 4: Determine your development budget and choose features

If you followed the last few steps, you should have created a stack ranked list of possible features, based on what matters to your most important customers.

You’ve also thought about some other attributes that matter, like: how recent the feature requests were, whether they’re in line with your longer-term vision, and how difficult they are to build.

Now you’ve got to pair the priority of the features with the resources that you have available.

Determine your development “budget”

It can be really helpful to think about your development team resources in terms of a budget.

That’s not how we normally think about our dev resources, but that’s what it amounts to: you essentially have a limited number of development effort days. A team of 10 devs has 100 effort days in a two-week sprint. If you were to convert it to dollars, the team has a “budget” of about $1 million to $2 million per year.

Product leaders, executives, and founders all have a responsibility to “spend” that budget well.

Consider breaking up your budget into “buckets”

If you’re thinking about your resources like a budget it’s easier to see how you can invest in different “buckets” or “envelopes”. Here are some we use:

• Customer requests. These are features your users are asking for.
• Strategic features. These are features you think your users will love but that they might not have asked for.
• Tech debt. These are fixes to make existing features or technical infrastructure better or more efficient.

For example, Superhuman takes an approach where they invest 50% of their resources in “vision” features (things they think their users will love but haven’t asked for) and 50% in requested features (things their users have explicitly requested).

You can choose your own strategy, just make sure it aligns with your business goals priorities.

“Spend” your budget on the best features

Here’s the part where you make a decision. And you should have everything you need:

• A sense of the features that are important to your most important customers, and, if you were to build them, would support your business strategy.
• A sense of the feature requests that are recent, in alignment with your vision, and how much each “costs” in terms of dev team time.
• And a sense of how much total time you have to “spend” on various types of features.

Now make some choices.

Fill your product roadmap with the features that score the highest in terms of the prioritization you’ve done. Try to make it roughly fit into the budget “buckets” you set.

Remember that while a good prioritization system should take into account feedback and requests from your customers, prioritization is a bit of an art. Data should inform your prioritization process, but perhaps not determine it.

Step 5: Do a sanity check with your internal stakeholders and teams

Finally, take your priority list to your stakeholders to do a last check that the features you’ve chosen to build make sense for them and that you’ve made the right calls.

This will help ensure you pick the right features, but it will also get everyone on board and continue to be motivated to share feedback in the future. Two keys to getting stakeholders on board are:

1. Using customer evidence to make your case for one feature — and refute ideas from people who have less grounding in the customer data.
2. Socializing your development roadmap early and often.

Use your feedback data to justify choosing one feature request over another. Screenshot by author.

Prioritize feature requests effectively to build a product people want

You need to be able to pivot your product effectively to get sufficient product/market fit and ultimately stay relevant. Knowing what you need to build so that you can continue to meet the needs of your customers is essential.

You do that by gleaning insights from your customer feedback, prioritizing their feature requests, and then acting on that feedback.

There is no shortage of product management prioritization strategies out there. But many of these are limited because they don’t connect your prioritization with what your customers want.

Don’t miss that important step. Make sure that customer feedback features heavily in your roadmap and product decisions.