When should you add a new feature to your product?

simonswords Product management

One of the greatest (and most time consuming) problems a great deal of product companies face is whether they should add feature X to their product.  The gurus over at 37 Signals have a policy of saying no to new features by default. While this is a great strategy, and keeps their apps focused and much easier to manage, this is a very difficult stance to take as a new start up. Fear Of Missing Out (FOMO) will keep even the most steadfast of product managers from staying true to saying no when a potential customer is waving a Visa card at them.

On our feature request forums over at Staff Squared we receive new ideas for our app every week. I’m constantly reading through the feedback we receive, looking for features I believe will increase sign ups and keep us hitting our targets. Therefore it’s incredibly difficult for me to say “No” too.

Understanding this is a weakness of mine, I’ve put a simple checklist of questions in place that I run through for every new feature request.

The questions are separated in to three phases. If the feature doesn’t make it through phase 1, we don’t bother with phase 2. Similarly we don’t go on to phase 3 if the feature doesn’t make it past phase 2. This approach has saved us 1000’s of hours in wasted development time.

Phase 1 – will this feature increase purchases of our app?

  1. Will people buy because we have added this feature?
  2. Will people not buy because we lack this feature?
These two questions are designed to focus our minds on whether the addition of this feature will make a material impact in the number of people buying our app. Other stats are nice, but money talks the loudest.

Phase 2 – what is the benefit of this feature?

So if we’ve passed phase 1, we are now in a position to dig deeper in to what type of ROI we expect to derive from the work we plan to do. At this stage we need to make sure that if we’re going to add features we need to have a clear ROI story. For example:

  1. This feature will add more customers
  2. This feature will convert more existing customers on trials
  3. Our existing customers will pay more if we add this feature
  4. This feature will reduce churn rate
  5. This feature will allow us to gain more press coverage (and therefore more trial sign ups)
A good solid strategy to follow regarding the product development cycle is the Kano Model . It takes into account how leaving out a feature or adding it in affects value to the customer. A milk jug is a common analogy for this:
Adding a thermometer strip to a milk jug adds value to the customer, but leaving it out does not diminish value. Adding volume to the milk jug adds value, but reducing volume reduces value to the customer. Putting a small LCD Display on the milk label adds value, but adds more value than the customer is willing to pay for. Certain features a customer will be willing to pay a lot more to have incorporated, and certain features only have a limited amount of value.

Phase 3 – the devil is in the detail

Having successfully understood and demonstrated ROI on the new feature, we can now dig further in to the detail.

  • Does this feature resonate with our value proposition, vision and values?
  • Will this feature make my product better for my target audience? (Note that target is an important word in this question, you only care what the people buying from you think)
  • What metrics do we think this feature will improve? How will we measure it?
  • How long will this feature take to build?  (Very important to understand the cost versus revenue generated so that we don’t labour for months over a new feature that won’t generate significant revenue)
  • Does this feature overcomplicate my product?

What if we can’t answer some or all of the questions on our own?

In some cases it’s simply not possible to know the answers to the above questions. At this point your best bet is to reach out to your customers (or potential customers) and interview, survey or split test for demand. Personally I struggle with this type of work as it is laborious and I understand that I might be given feedback I don’t want to hear. However, good developers aren’t cheap, and this approach has saved my backside on a number of occasions.

Leave a Reply

Your email address will not be published. Required fields are marked *

*