Choosing the features of your software product
/A common question from our software customers are “how do you choose which features to add in the software?”. See the problem in most cases isn’t a lack of feature ideas, it more a problem of too many feature ideas. And there are two good reasons for not trying to add every feature you can think of into your software:
Too many features confuses your users and reduces software use and thus sales.
Features are expensive to build and maintain (of course!).
So software product management is the science (and some would argue an art) of finding the right features and prioritizing them based on the needs of the business. Having worked with hundreds of software projects over the years with companies tiny to massive we’ve come up with some strategies that seems to work most of the time, and today’s post is about those strategies. However, something remember in this space is that every software product is different, not just in it’s domain but also in the type of end users and their worldly problem the software is trying to solve. So always view these strategies with the filter of your particular niche to figure out what needs to be different for your particular product.
The 80/20 rule works for product features too
The Pareto principle otherwise known as the 80/20 rule says that: “… for many outcomes, roughly 80% of consequences come from 20% of causes”. Put in the context of this post’s topic it translates to: 20% of the features you have in your full blown software would server 80% of the real use cases of that software. And if this was true, if you could do only those 20% features, you’d really be ready with a software that was good enough for 80% of your user’s needs!
Now the Pareto principle might be one of those rule of thumbs laws, but there seems to be some hard data that points to the truth of this principle in the world of software. A good source of such data is the Chaos report that the Standish group runs around the software industry. In one of the first studies they did for software feature usage back in 1996, they looked at 100 custom applications to look at the functions and features requested, implemented, and used.
Here’s what they found in their own words: “The study was done in two steps.
STEP 1: We took an inventory of each feature and function.
STEP 2: We held user workshops to find out which features were used.
We learned that only 7% of features were always used, another 13% were often used, 16% were sometimes used, 19% were rarely used, and 45% were never used. The study was very long, difficult, and expensive. Using some automated tools and spot checks every couple of years, we found, to no surprise, that the numbers are relatively unchanged for most methodologies. Our current thinking is that 20% of features are often used and 50% of features are hardly ever or never used. “
So finding those 20% features, or as sometimes described as the “vital few” features are very important. Those features will need be prioritized and built first. And if doing them requires you to ditch many others accept that as price to pay.
The question is of course how to find those 20% vital few. And the next few strategies help you zero in on those features.
Use user group feedback to prioritize
At the end software is being built for users. So it should be users who identify the most important features (those vital few 20%). With this principle in mind you need to aim to arrange a user group that consists of “typical” users of your software. So for example, if you are making an HR software, your user group should be HR staff of various companies. It’s usually easy to recruit the users from your own company (you might need to tempt them with food and drinks!) but you should definitely try to get some people from outside of your company too. The reason being that you are looking for diversity of views - things are probably done in different ways at different companies and the more variety of input you get is the best. Once you form a user group, setup up events (ideally physical events where people can relax and talk) where you invite the group members and seek feedback from them about your software features. Here are some ideas for gather data:
Run a demo of the software (even if they are just mockup pictures) and then ask people to vote for each features. Count the number of hands going up (or even formal votes in paper or apps) and decide how popular are the features.
Setup a survey and ask people to fill in (not the best for people, but really good for you, so you might have to bribe them with food and drinks or prizes!).
Show a single feature and then explain how it solves the problem they are having and then ask them if it really does solve the problem. Be ready to be surprised by the debate that sometimes arises from this! Make sure you are tracking all the feedback. The more people have strong views about a certain problem the more important that feature is (the vital few!).
Play a game that let’s people select certain features. This could be a game of throwing a ball into baskets with names of different features with a plan that you’ll put that in the working list (and you are looking at which baskets people are most interested in. Here’s a great game idea called the “buy a feature” where you give the users monopoly money and tell them to go feature shopping!
Use tracking data to find user interest
This is idea is one of the best approaches for a data driven decision making on software product features. The concept simple, track which features of the app users use the most or has the most interest in. Usually it’s done in two distinct phases:
Before product release
This is where you are thinking of which features to add in your as yet unbuilt product (or unbuilt new version of the product, i.e. you’ve got a product out and planning for the next update of the product). So in this scenario you don’t have a way to track the actual use of the feature (as it’s not yet built) so you have track user interest in descriptions of the product. One common way of doing it is having a list of upcoming product features in your webpage and then using a visitor analytics tool like Google Analytics to track user visits and clicks about those features. A really cool way of getting a much richer analytics than pure visit counts is to look at how much time people spent on a certain page, where they tried to click the most (or had their mouse) with a web page heatmap tool like Hotjar.
For a great example of how new features can be talked about is Trello’s page about upcoming features for their big redo back in 2021. Note that Trello can be quite verbose as it has a very dedicated user group who have been using Trello for sometime and has direct interest in reading through details. Your brand new app might not have that level of interest for visitor on your site, so you are likely to have a much shorter attention span and images are your best route in gathering user interest. Have large screen mockups (the ones you preparing for the feature description anyway) on your page with short but punchy intros for them. And then use your cool trackers to find out if users are actually spending time looking at the pictures at all.
After product release
Once you have your software up and running you have much better way of tracking user interest. You should setup analytics tools that report usage of different features and sub-features. Any upcoming feature should be planned based on areas where the usage is the most. You can also have features that are not with all the bells and whistles but at least gets the user to do part of their task with them. And then you could see the interest and usage on those features to decide if the next version should have a more complete version of that feature area. An example for this approach could be say an HR software planning to introduce an ID card generation tool - being an HR software it has all the data, so generating ID cards ready to send to a printer might be a great tool (or it may not be at all!). So one way to test this could be to give a card generation option that just gets a plain vanilla card out. Now if the tracking shows that many users actually tried that feature out that would a signal for the company to invest development time in creating well designed ID cards (maybe with options for adding color, company logo and other custom design options too).
Use public forums, reviews and discussion groups for finding pain points
This is another time honored way of finding priority features for your product. The process is to first identify a list of public forums, discussion groups, review sites that are roughly in the same space as your product. And then painstakingly go through those discussions to find common themes that people are complaining about either because there are no products out there that does what people are looking for or the existing tools are just bad. By finding common themes and by looking at the volume within those themes you are essentially finding the “pain points” that need solving in your product space. And this research can give the data for prioritizing what pain point needs solving more than others. That leads to your feature list!
This a common process that many big companies use themselves to identify feature enhancements. Microsoft’s strategy for a long time was to launch a half baked product and use the product forums to find where people are complaining the most and fix and enhance those (and only those)! But leaving the giants aside, the research in discussion forums is absolutely essential for any feature planning. The best thing about this approach is that the data is already out there, you don’t have to invest time and money is building out tools, wait for data to come in and then make those analysis.
Product development is expensive and it takes up precious time and energy. It is very important for spending your limited resources at the right places. Choosing the right features in your product road map and getting them built in stages in synch with usage and interest is one of the key aspects of making a great product.
