Feature Requests – Do or Do Not?

So you’ve built a great product, with a clear vision of the product’s value and its future. Your product starts getting traction with lots of customers. Suddenly, customer feature requests fill up your inbox. You get overwhelmed by the different directions these features will take your product and they are not part of the original product plan.

What should you do?

Not to worry, this guide will help provide a structure to decide and prioritize what to do with your feature requests.

Default to say ‘No’

With any new feature request, the initial response should be ‘No’.

But wait, the customer just asked for that feature point blank, and isn’t the customer always right? Generally, when customers make a request, there is a legitimate reason why. However, some customers might not know what they want. You will need to look deeper and have the data to figure out what features are actually valuable, to avoid distracting your product and team’s focus.

Some of the questions you need to ask for each request:

Is this feature critical to preventing the customer from canceling their subscription?

Is it adding only a slight increase in the user experience for a few customers?

Is it urgent and/or valuable? Does it have a large scope of change?

Is it worthwhile to do this right now i.e. future proofing?

Is this feature aligned with our mission/goal?

Is this feature worth the impact/cost?

Moreover, even if a customer is being vocal, they might be the minority. It is important to target requests that come from a customer segment that you’re focusing on.

If you receive a request and it doesn’t align with your product strategy right now, then toss it out, even if it means some unhappy customers. Do however ensure that the customer making the request feels heard. This can be done by communicating openly and setting expectations about your product roadmap, including why the feature being requested will not be included.

If you decide to agree on a feature request, push it on a product backlog for prioritization.

You need to be careful of feature creep – adding too many features that distract the product and dilute your MVP product offering. Remember, with every new feature addition, there are costs associated with it – new testing, documentation, screenshots, videos, maintenance etc.

Implement an 80/20 Rule

Focus most of your time on improving current features with an 80/20 rule – 80% existing features, 20% new features.

There is always a temptation of running after that shiny new thing, however, you should focus on improving your core product. Limit the number of features that are being worked on concurrently and focus on the few that matter.

Additionally, “dog-food” your products internally in teams so you are constantly testing and can better understand your customer’s experience. As a product manager, have continuous communication with the internal team and gather feedback on what needs improving.

Rank the feature requests on the product backlog

Even with the 80/20 rule, you could still work on the wrong features. Incorrect prioritization is one of the most common major wastes of time. So, when prioritizing your product backlog, keep your product and business goals clear in mind.

To quantify the prioritization of features, rank and compare the features based on agreed metrics of importance. For example:

Technical Feasibility – based on the technical capability of the team, how much time would this take?

Customer Desirability – based on market research, how much will it improve the value to the customer?

Business Viability – is it going to make money?

Here is an example of what a prioritization board can look like:

Feasibility

Desirability

Viability

Total

Feature #1

3

4

9

16

Feature #2

6

8

7

21

Feature #3

5

6

7

18

From the above table, we would order #2 first, then #3, and finally #1.

You may decide on other aspects of a feature, or give different weights to each column. What is important is that the team agrees on how each feature is being measured.

With these frameworks, you should be on your way to prioritizing and making informed decisions on feature requests that address customer pain points.

About Jonathan Kurniawan

Hi! I'm Jonathan Kurniawan. I have 4 years of experience working as a software engineer at Dolby on various different products. I'm currently pursuing my MBA from Hult International Business School and received my Bachelor in Computer Science from University of New South Wales, Australia. I'm excited to share my knowledge at the Data School by Chartio.