Part 1: What Features To Add And When
You open up your email to a list of feature requests from customers. The emails go something like this;
“I think your software has good potential. It definitely needs X though in order to be really useful”
or
“Great program! Are you planning on adding X? When you do I will buy it.”
Now you rush out and make sure the next update has X in it. You don’t put a lot of thought into how its going to be implemented, you just know it has to be there. If your product doesn’t have X its not any good. Oh and wouldn’t it be really cool if it had Y too. You can’t have X and not have Y. If I don’t add X, Y and probably even Z, no one will buy my software again!
Sound at all familiar?
When you get that new feature idea in your head, you start to wonder, how did my software not have this feature before?
Adding feature X won’t necessarily benefit your software. Why? Features don’t sell software. The ability for your software to quickly solve a problem is what counts. Now you have to ask yourself, will feature X (and Y and Z) really help my users solve their problem much more quickly?
Some things to consider about new features;
1) Not all users need these features
2) Most users won’t even know they exist
3) Most users don’t use your software the same way, and won’t have any use for that feature
4) Features add software bloat and software bloat adds confusion and requires more training to use your software
5) Creating a solution to a problem that people don’t know they have is difficult to get users to understand. So just because a feature might help improve productivity, it may be tough to convince a user that they need it. This afternoon I was sitting with a friend who was using Internet Explorer 6. I told him he has to get FireFox to use tabbed web browsing. He said to me I have no problems with Internet Explorer, why should I change? He has never used tabbed web browsing before so he didn’t know how much it could improve his web browsing.
First, and most importantly, you have to know how many people actually need that feature in one form or another. If a lot of users are requesting a certain feature, you have to move it up on your to do list.
Here are a few things to consider;
1) Define what your program is most used for, the major problem it is trying to solve. Not what every single user may be using it for, just what the majority (70%+) might use it for. This will be called your Core Problem. The Core Problem is the problem your software is providing a solution for. You can have multiple Core Problems, but try to limit them to what the majority of people would use your application for.
Example: Link Checker
Core Problem: Help me fix all broken links on a web site
2) Separate Feature Requests into Categories
Core Features: Core features are those features required for your application to actually solve its Core Problem. If they are not there, your application would pretty much either do nothing, or it would be more convenient to do what it does manually.
Example For Link Checker:
Spider to scan/check links
List of broken links
Error number for each broken link
Which pages contain the broken links
Without the above features, your software would pretty much be useless. If Your link checker didn’t report the error code for a broken link, I would have to go an extra step in order to find it, which would make fixing it harder. Competition often defines what can be considered a Core Feature.
Convenience Features: These features make using your software easy to use. They don’t contribute to the Core Problem, they just provide a more pleasant use of your software. These include; undo/redo, Open Recent menu listing recently opened documents, auto check for updates, auto install plug-ins, keyboard shortcuts, spell checking, speed improvements and optimizations etc… They make solving the problem even faster than before by fixing little bottlenecks in the software design.
Functional Features: These features add additional functions and uses to your software. They are hard to determine because they may help with the Core Problem. To distinguish them from Core Features and Convenience Features you must consider these points:
1) Are there many other applications out there that perform this function? Do they do it better than you ever could? Are there standards that your customers are already used to?
This question helps distinguish the Functional Feature from a Core Feature. For example, adding an FTP Client to an HTML Editor to upload your web page files. This is not completely necessary and there are many third party programs that already do this really well. In this situation it may be better to integrate two separate products than add in an FTP Client.
2) Is this feature always required in order to solve the Core Problem of your software or are there just special circumstances where this feature can be used?
3) How many users can take advantage of this feature? Does it require expert knowledge? Can your target customer take advantage of it?
If only a small percentage of customers will actually have the knowledge or capabilities to use the new feature, it may not be worth implementing until more critical features are added.
4) Will it require a change in the category your application falls under? For example, you have a file browser and you add the ability to open Text files, Picture files, Movie files, Audio files, etc… and make quick changes to them. It now crosses the line between “file browsers” and “File preview tools”. Define the boundries of the category your software falls under so you know when your crossing that line.
There is nothing wrong with adding Functional Features. Functional features help attract more customers by stretching to more markets. All you are doing at this step is determing how to rank features based on the usefulness to your current market. However, you should always make sure core features are implemented first, then convenience features, and then functional features.
While working on a version 1.0 of your software, knowing the kind of features you are adding can help reduce the problem of never getting a final product out. It can help you decide which features must be added for version 1.0 and which feature can come in an upgrade. Functional Features can usually come in major upgrades at later times.
Using the above strategy does have its problems. It is subject to personal opinions of the developer. It is often hard to determine the difference between Core, Convenience and Functional Features. How you define them may be related to how you define the Core Problem. However, if you use this method of thinking, it may help you spend your time more efficiently and make your decision making process a little easier.
In my next post I will talk about how to decide on which features to actually add to your application by looking at each feature using four additional criteria.