Entrepreneurs, developers and investors devote a lot of effort and energy to identifying a new project's Killer Feature. They hope this feature will engage users and create the stickiness that will draw them back to the project again and again. Much has been written about the importance of a Killer Feature, but would you know one when you see it?

Only Users Can Determine A Killer Feature

It must be a very challenging task, because at the end of the day, only the app's users will determine whether any feature has the elusive "it factor." That uncertainty is pretty scary. Starting an Internet project requires significant investments of time, money, connections and energy. We hang our hopes on the assumption that users will love what we think will be the Killer Feature.

But since we can't be sure whether any given feature will be a Killer, startups often add multiple features, hoping that if one doesn't turn out to be the coveted Killer, maybe another will. They consider this a risk reducing strategy, but it's actually counterproductive.

Tailor The Suit To The Clients: Users appreciate simplicity. They like apps and websites that are easy to understand, and they feel confident when they know they're taking advantage of what the website has to offer.

If things are too complicated or they feel they're not making the most of what's available, they can get frustrated and uncomfortable. In this sense, too many features that don't get used can be harmful.

The trick isn't to offer users everything. The trick is offer them exactly what they need,

Overloading your Project With Features Could Kill It: It's best to go online with a feature or two missing. Your users will let you know if there's anything else they need, and then you'll know those features are really necessary.

So maybe I've convinced you to carefully choose the features to include in your next startup. But how do you know which feature is necessary and what might be that elusive Killer Feature?

FUV: Feature Usage/Value ratings

First, make a list of all the features you're not sure about.

If your project is about issue tracking, you know that "Open a new issue" is a necessary feature. The project wouldn't work without it.

Instead, focus on features that raise doubt. If you're not sure a certain feature is crucial, add it to the list.

Second, evaluate and rate each feature according to two criteria:

What percentage of users are likely to use it

How much value it will generate for users (on a scale of 1 to 10).

Pay special attention to the factors that may distort your ratings:

Percentage of use. Different people have different goals, needs and motivations. This leads to different usage of the same system.

Project managers would use an issue tracking system somewhat differently than their clients or than developers or designers. A project manager or a client may spend most of their time creating new issues, while developers would mostly try to understand them and update their status.

It's critical to consider all potential users of your system (usually in the form of user 'personas'), and the different ways they each one might use it. It's best to go through this process for each persona.

The value contribution of a feature. This is often the biggest obstacle. We tend to fall in love with our inventions, especially if we think our invention has got what it takes to be a Killer Feature.

But how can we tell if it's really worthy?

Ask yourself and your team: What would happen without it? Would the users know their way around the system without it? Would they notice it's missing? Would it be easy to learn it and adopt it? Would it be used on a regular basis?

Once you've rated all the features on your doubt list, the next step is build a diagram that depicts your features' percentage of use and value ratings.

Now it's time to determine how strict your feature inclusion policy should be. A rule of thumb is that a feature should be useful to at least 50% of users, and should have a value rating of at least 5 out of 10.

This is a pretty lenient guideline… the more you believe that unnecessary features alienate users the higher the usage percentage threshhold should be. The more you believe that every feature should be outstanding, the higher you should set your value rating minimum.

Mark your minimum ratings on the diagram, as shown here:

The diagram makes it easy to tell which features should be included. If it's in the yellow area – it's in the project. As for the rest – better luck next time. (Of course, it's wise to reassess your initial ratings as things change.)

Stalking The Killer Feature?

At this point, you have a visual guide to identifying the killer feature.

Notice the green dot at the top right hand corner of the diagram. It represents a feature that an estimated 100% of customers would use, and they would feel it gives them a 10 out of 10 value. That definitely sounds like something worthy of being called a Killer Feature.

You won’t always have one of those, of course. In those cases, the feature that comes closest to perfect ratings is your best candidate for the role of Killer Feature.

Finally, notice the red dot at the bottom left hand corner. Any feature with ratings like is a Startup Killers - make sure it never makes it into your project!