Why your feature request backlog is probably useless

The Sweet Shop science behind prioritisation and why it’s essential for your feature requests

The problem with feature requests

If you ask your customers they would like almost everything from your backlog of feature ideas, ask your sales team and they want the features to close the next big deal, talk to support and they want the feature to fix the problems of their most persistent and irate customers and so on…!

The simple truth is that you can’t act upon all of this feedback until you understand where feature requests are coming from and what their priority is. At the moment, most SaaS businesses are missing this crucial step. Instead, they are building the features they hear the most or which have the most votes, following the HiPPO or being swallowed by a whale.

These techniques give you some insights but we don’t believe they give you the full picture or right information. They certainly don’t give you the information you need to work out which features will add the most value to your product. We all have limited time and resources so it’s vital you don’t waste them building features that don’t matter.

I was recently listening to a SaaScribe podcast when Brian Balfour, VP of growth at HubSpot came out with a perfect description of the big challenge we all face:

“I’ve learned over time, no matter how big or small you are, you’re always constrained by resources. So you have to get really freaking good at answering the question, ‘What is the highest-impact thing I can work on right now given my limited resources, whether that’s people, time, or money.’“

Un-prioritised lists of “wants” are almost worthless to a product manager which is why we encourage our customers & teams to prioritise. Doing this important step always surfaces some surprisingly small features that can make everyone happy. This is particularly true with regard to customer requests.

Here’s a little story from my last SaaS business…

Building the most popular features is bad

We’d fallen into the trap of thinking that our customers wanted a particular feature because we kept hearing it over and over again; particularly during support calls. It had the most “votes” on our spreadsheet so therefore we (wrongly) assumed it would add the most value.

We never felt this approach really worked for us so we took the time to really understand who the feature requests were coming from (free triallers, churned users, paying customers of varying account value) and most importantly, the priorities of those feature requests.

When we folded in the value and prioritisation of our customers, the big features that “everyone needed” were nowhere to be seen! Instead we’d unearthed a ton of smaller, feature requests & feedback that our customers prioritised but most of which we’d never even heard of.

What a sweet shop has to do with all of this

OK, so here’s our “science” behind the surprising results or “The Kid in the Sweet Shop Problem” as we like to call it.

When you take a child to a sweet shop, they want everything. I have two children. This happens…every…single…time. However, when you ask them to prioritise (due to a cost constraint in this case — usually a fumble in the bottom of my bag in the hope of finding some change!) the understanding of what they really want changes dramatically. However, they will change their mind again…and again…until we’ve been in there an hour. Fun times.

The same goes for users of your SaaS product. Prioritisation should be dynamic and not static. Instead of gathering feature requests as a one-off task and asking for votes, you need to give users the tools to change their feature requests, feedback and priorities ongoing.

Again, like a kid in a sweet shop, priorities change so you need to capture that. For example, you’ll notice patterns depending on where the user is in the lifecycle of your product. Users going through onboarding will have very different feature requests and priorities to a seasoned user who’s been with you for years.

Moving from having a static, vote-based system to one which was dynamic and priority-based transforms your product roadmap. That’s when feature requests start to tell you something truly tasty.