🧮 A formula for prioritising feature requests

This post was originally published on Medium.

The most common question a product manager gets asked is “how do you prioritise features?” Ok… admittedly this is the second most common question after “where’s this feature in the roadmap?”.

Everyone has a slightly different answer. Some are honest, admitting “whatever the CEO asks for” followed by a deep sigh. Some will say it’s “whatever our biggest customers need”, others base their priorities on a popularity contest of “whatever gets the most votes on our roadmap”. Often it’s a combination of those three with some recency bias thrown in the mix.

It’s really easy to slip into prioritising the wrong things, or at the wrong time, taking your product in a direction you didn’t intend to take it in or leaving a lot of potential revenue on the table. There are whole books on this. Frameworks like RICE scoring and the Kano method help guide prioritisation decisions, but I’ve always felt they were too abstract and not linked tightly enough to customer requests.

A method I’ve adopted over the years to aid prioritisation is to give each feature a score which I refer to as “need weight” based on a few different signals that are captured whenever a user expresses a need. Need weight determines the heaviness of the feature, and the heavier the feature, the higher up it will appear in the list of features to pick from to work on next. I use it to help reduce recency bias and ensure we’re not over-rotating on features that are less likely to result in increased revenue.

The key signals I look for when prioritising include the popularity of the request (are lots of people asking for it?) the size of the company (is the request coming from a big enterprise customer or a free user?), and the urgency of the request (is this blocking a deal or just a nice to have?). I include all of these in the formula.

It might be tempting to only tune into just one of the signals. You’ll see this when you’re only prioritising the needs of your big customers, or reacting every time the urgency fire alarm gets pulled (which, guess what, leads to it being pulled all the time!).

There’s a lot more that could go in, but there’s really no point in having anything more complex than this unless you’re working at massive scale. Better to keep it simple. If you are at this scale though, you probably also want to consider some different score weighting for things like requests from customers who are coming close to a renewal, and the effort required to ship the feature.

Let’s assume you’re being diligent about collecting needs from your users — you’re logging every request that comes in with who requested it and what the urgency of the request is. You’ve also hopefully also got some form of CRM which includes details about the account (the plan they’re on, the deal size or ARR and whether they’re a prospect or in a contract).

The need weight for a feature is calculated by mapping each bit of information to a score, combining it into a total score for each individual request, and then combining the total need scores for the same feature.

That sounds a little complicated so I’ll walk you through each step in that process.

To make the formula work, urgency and company size need to be normalised into a score. Number of requests is easy since it’s already a number — just make sure you’re deduping repeat requests from the same company as this can inflate the total weight (unless the duplicate requests are from different teams that equate to different accounts).

There are a few different ways you could determine what score to assign to a company, such as:

I tend to score company size by the plan they’re on if I have no other data to pull in. This has the downside of inflating existing customer needs over the needs of potential ones who haven’t yet converted, and is also not a great indicator of future potential growth. Something like potential seats is probably a better data point, since it gives you an idea of what the size could be rather than just what it is today. It really depends on what data you have to hand and what you bill on though.

Here’s how that plan-to-score mapping looks as code. This is using Airtable’s formula syntax, but it’s a basic IF loop, falling back to a score of 0 if something gets passed in that doesn’t match any of the conditions.

When feature requests come in, the urgency of the need should be logged alongside it. It’s important to know whether a request is just something the user would like to see in the product, vs something that is a revenue blocker. Feature requests that are blocking revenue (a new deal, adoption, renewal, expansion) should be really high on your list, so you want to give those the highest possible score. As an aside, I like to get a notification every time those come in so I can dig deeper.

Here’s how that looks in code. This one’s a little more complex since I have multiple different categories for blocking needs so I’m looking for any that start with the word “Blocking”, but those all get the same score. Like in the example above, I’m falling back to a score of 0 if something gets passed in that doesn’t match the conditions.

The scores I’m giving in both examples are linear, but you can play with the numbers if you want something to add a lot more weight to the total score.

Now you’ve got the raw scores, you can add them up to get a score for each feature request, then add those individual request totals up to get a combined score for each feature.

For each request:

For each feature:

You can see how that all these scores all work together in this example Airtable base. 3 tables are in play here — one for companies, another for the requests with a record for each request, and a third which is the features with the combined need weights from those tables. You can use pretty much any database-type tool to run this same thing though, or pull raw data into a BI tool and do the calculations there.

Following the need weight solely will make you a more efficient feature factory, but still a feature factory, so use these scores as a guide and not a rule. Your product strategy needs to encompass more than just customer signal — it needs to be pointed in the direction you want to go in as a business.

Here are a few other things you should be considering alongside need weight when prioritising:

There is no perfect formula or framework for prioritisation — I don’t think there can be, there are too many fuzzy variables. What we can do though is build stronger signals to help make better, more deliberate and more informed decisions.