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?
- Will people buy because we have added this feature?
- Will people not buy because we lack this feature?
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:
- This feature will add more customers
- This feature will convert more existing customers on trials
- Our existing customers will pay more if we add this feature
- This feature will reduce churn rate
- This feature will allow us to gain more press coverage (and therefore more trial sign ups)
- 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.