How to Prioritize Product Feedback (Badly)

As a wise man once said, “Anyone can prioritize feedback. It’s prioritizing feedback right that’s hard.”

Okay, so full disclosure, that wise man is me, and that’s literally the first time I’ve ever said that in my life. But the point still stands.

There are literally dozens of different ways in which product managers try to prioritize the feature requests and feedback that falls into their laps on a daily basis.

That’s the good news; you’re spoiled for choice.

The bad news? Well, I’m afraid that a lot of the tried ’n’ tested ways of prioritizing aren’t actually that effective when you scale and they can even do more harm than good, leading you to spend time on things that don’t have a positive impact for your customers or the business.

So I put together this list of methods that you’re better off veering away from when you start to build SaaS products at scale.

Consider this your warning…

The Kano Model

Named after its creator, Noriaki Kano, this model was first introduced in the 1980s.

It revolves around measuring how satisfied a customer would be with a feature, and how functional the feature is. You can then plot the features on a graph. The features that are both highly functional to the product, and would satisfy your customers, are the ones you build.

I suspect the popularity of the Kano model stems from the fact that it makes sense. It has a high level of face validity (and people told me my Psychology degree was worthless…).

But there are a couple of major limitations with the Kano model when it comes to SaaS products at scale:

Firstly, it’s a lot of hard work for both you and your customers. To get the information you need to make this model work, you have to subject your customers to tedious questionnaires that seem to go on forever and ever.

And even if you manage to get the data, how much does it really tell you? Pretty graphs don’t make MRR or solve your customers’ problems. You need insights. Data without insights is like a pizza without toppings — bland, uninspired, and honestly why would you not want toppings you weirdo?

The features that your customers rate in the boring questionnaire are ones that you’ve thought of. What if you missed something? What if you didn’t think of other features that your customers would like? What then?

As you can see the Kano model is rife with limitations. Let’s move on.

Buy a Feature

No, this isn’t my pitch for a new board game. This exciting sounding method involves people spending a set budget on features. This way you can see the features that they value the most.

If this sounds like a poor attempt at an ice breaker, that’s because that’s exactly what this sounds like. Now, I’ll be the first to admit that this is a clever way of getting your customers or employees involved with prioritizing your feedback. Everyone loves a game, right?

But, and of course there’s a but, the prize for playing this game isn’t as valuable as you might think…

The good part is that your customers are prioritizing. They can’t choose every single feature and so they’re forced to pick the ones they want the most.

But, once again, they haven’t submitted these features. It might be that they have other things they want that simply don’t appear in the game.

Besides, should you really be talking about features with customers anyway? Capture user problems, then design the solutions. If you talk in terms of features you’re missing a trick!

It also takes a lot of time & organizing. It generally works better face to face so that means you need to arrange for a group of customers to get together and play the game, and if you’ve ever tried to organize a games night with friends you know how hard that can be.

Buy A Feature looks fun, but fun doesn’t pay the bills.

Prune the Product Tree

Here’s another game. This one’s called Prune the Product Tree and it kind of sounds like something created by Mr Miyagi.

You start by drawing a large tree, maybe a nice sturdy oak, or a wintery pine. The thicker limbs represent core product areas and the outer branches are available features. You then ask customers or team members to place the features they want on the tree.

The idea is that you can then see if the tree is shaping up nicely, identifying the areas which are over or under-developed.

Again this only works in small groups and on a small scale. It doesn’t involve everyone or capture changes over time. Maybe, if I was feeling generous, I could advise using this to help organize your own thoughts. But you know what, I’m not feeling generous and so all I’m going to say is that this will not lead to customer insights and scalable feedback.

I’m all for planting more trees, but maybe not this sort, okay?

Value Vs Effort

Let’s move away from games before I turn green and go on a rampage. Next up, Value vs Effort. The way this works is simple. Each feature is assigned a relative value of how much it will bring to your product, and a relative cost of how much effort it will take your dev team to build.

So far, so good.

You can then plot features on a graph and immediately identify the features that are high value but low effort, and these should be your priorities.

Receptive actually includes a version of this method and our customers use it all the time. But that’s only one part of Receptive. Using Value vs Effort on its own can only get you so far. It’s kind of like trying to make a cake without sugar. It looks like a cake but it sure as hell doesn’t taste like one.

What if, for example, a feature is ranked as low business value and high effort? Chances are you’re going to ignore that feature. But what if 80% of your customer base really, really, really want that feature because it solves a huge pain point for them? Shouldn’t you take another look? Value vs Effort only gives you part of the picture so just be aware of that when it comes to your roadmapping decisions.

I don’t see the value in it, and it’s costing me a lot of time. I need to move on.

Ending on a High Note

The one thing that all of these prioritization methods have in common is that they are seriously time-consuming. That’s fine if you’re small, but they’ll hold you back if you are serious about product feedback and prioritization at scale.

Unless you’re a startup or small business, these methods will distract your product team creating a lot of unnecessary work for very little return.

That’s all from me, I’m off to play a fun game of Prune the Product Tree. Can’t wait…

Leading SaaS companies use Receptive to build winning products. Want to join them? — receptive.io