🔗 A formula for prioritising feature requests

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.

continue reading on medium.com

⚠️ This post links to an external website. ⚠️