Handling requests for new features in a successful product

If you have a successful product and your users ask for new features that really make sense, then you’re in an enviable position.  However, the way in which you choose handle these requests can play a big role in the product’s future success or failure.  In my experience there are several alternatives worth considering:

Do not develop the feature at all

This is the baseline assumption for any potential new feature when you already have a successful product.  Adding a new feature will always cost time and money, add technical complexity, and complicate the user interface.  To justify developing a feature, you must be convinced that the reward justifies all the cost of its development.  It might significantly improve the customer experience, it might make new customers want the product, it might make existing customers pay more for the product, and so on.  If you determine that the expected reward justifies the estimated time, cost and added complexity, then the feature can move on to one of the categories I’ve outlined below.

Add the feature to the base product

Is the additional feature integral to the core purpose of the product?  If it is, then it is a good candidate to add to the base product.  Designing the feature should focus on incorporating it seamlessly into the existing product – carefully selecting where in the user’s workflow it is presented and what menus are used to access it. You should also consider whether any existing features should be adjusted, or removed, as a result of adding the new feature.

Take a messaging app as an example: the ability to send a message to multiple people might fit this category. Based on the existing app, the product team would decide whether to only allow the first message in a conversation to go to multiple people, or if multiple people could be added to the middle of a conversation and view the previous messages in that conversation. Existing privacy features might then need to be reworked to account for this new feature.

If the feature is only tangential to the core purpose of the product, or if the result of this design process is that the new feature simply cannot be fitted in without damaging most users’ overall experience using the product, then it probably belongs in one of the categories below.  The ability to send a physical piece of mail to the person you are messaging might fall in this category for a messaging app.

Add the feature, but only show it to power users

A feature that is very useful to a small subset of the products’ users, but only creates confusion for the majority of users when it is included in their experience, can be included in the product but hidden from most users’ view.  The user experience design is critical here.  Make sure that users who do need the feature can find it.  Building a strong user community is another way to make these features successful – the most active participants will often be power users, and they will ‘talk up’ the newest power features so that others who are interested will know to try them out.

A small percentage of the people using a messaging app might be fundraisers corresponding with donors, and expected to send physical thank-you cards.  These fundraisers might be happy to pay to automate this process, but the majority of the app’s users will never have any desire to send a physical card.  You might want to add this feature but not make it prominent, and then start a conversation with the portion of your user community who are fundraisers.

Spin off a new product

If you have a set of features with a strong case to be developed, but they are not integral to the core purpose of the existing product, you may want to spin off a new product.  This can feel like the riskiest option, but it can actually increase the likelihood of continued success for the existing product by avoiding feature bloat.  Plus, the new product can often start out as a very simple one that requires a limited investment of time and resources.  You may be able to launch it with only some of your time plus the time of the people who would have added the features to the existing product instead.  Consider treating it as an experiment – build and launch in a simple, cost-effective way and see whether the new product is viable.

You might discover that fundraisers really like using your app to message their donors, and they have a lot of other needs too – not only sending physical thank-you cards, but measuring the donations given based on different types of messages, keeping track of how much each donor has donated, and so on.  They might like to do this all within your app because they already spend so much of their day using it that having everything in one place would be a big benefit.  Adding all of these features to what is fundamentally a messaging app is likely to make it too bloated for all the other users, so it makes sense to think about spinning off a new product targeted to fundraisers.

This is one approach for thinking through the options for new feature requests. I’d be interested to hear what other approaches you have found to work well.