How to find your killer function

I'm sure there are many entrepreneurs, developers, and investors who have spent a lot of time identifying the killer features of new product types. Because they want to be able to use these features to attract users, and then let users again and again using the product. And most people have published many articles about the importance of killer functions, but the real question is, when you see it, can you identify which features are killer functions?

Only users can determine killer functionality

This must be a very challenging task. Because, when a product is launched, only the actual users of the application can determine what kind of work will make people feel ambiguous. And this sense of uncertainty is really scary. Because starting an Internet project requires a lot of input, including time, money, connections, and even energy. And we will certainly want the user to like those features, directly is the killer function.

But what? We can't really be sure which of the specified features will be the killer, and startups tend to add a variety of features, even if one of them doesn't become a killer, and they want another killer feature. They do this as a strategy to reduce risk, but in practice they often fail to achieve the desired goal.

Tailored for customers: users like simplifying. They like app apps and Web sites to be easily understood, and they feel very confident if they can understand what they can benefit from the site.

If the Web site or application design is very complex, users will feel very poor usability, and it is easy to make them uncomfortable, more frustrating for users, too many unusable functions is actually very bad.

Some tips don't provide the user with everything, and these techniques should give users what they really need.

Too much load on the project is deadly: Your users will let you know what else they need, and then you will know what the necessary features are.

So, how do you know which features are required and which can become killer features?

FUV (Feature usage/value): Functional use/value rating

First, you have to list all the features you are unsure about.

If your project is about problem tracking, you'll know that "opening a new problem" is a necessary feature. This project does not work without this feature.

In fact, focus on the functions that are constantly producing suspicion. If you're not sure whether a feature is critical, write that feature on that list.

Second, each function is evaluated and rated according to the following two criteria:

How many hundred percent customers can use it?

How much value it gives the user (ranging from 1 to 10 points).

Pay special attention to the following factors, which may affect your rating:

User group segmentation. The purpose, need, and motivation of different people are not the same. This leads to a different use of the same system.

The project manager's use of the problem tracking system must be completely different from that of his client, or programmer, or designer. Project managers or customers may spend a lot of time creating new issues, while programmers spend most of their time understanding problems and updating problem states.

It is important to consider the potential users of the system (usually in the form of a user "role"), and the different ways in which each user may use the system. The best way to do this is to go through the process of using each character's system.

A functional value contribution. This is often the biggest obstacle. We tend to fall in love with investors, especially when we think our inventions will become a killer function.

But if this function is really valuable, how can we describe it?

Ask yourself and the team: what happens if you don't have this feature? If the system does not have this feature, will the user know? Will they be aware that this feature is not available? Is this feature easy to learn and easy to use?

Once you suspect that the list is rated for all functions, the next step is to create a chart that uses proportions and value ratings to draw on the diagram.

Now it's time to decide what your functional value policy should look like. One rule of thumb is that a feature should be useful to at least 50% of users, with a value rating score of at least 5 points (10 points).

This rule is actually very broad in scope ... If you think that the more important a feature is to a user, the higher the threshold for using a percentage.

The more you think that every function needs to be good, the higher the minimum point of your value rating will be.

Mark your lowest rating on the chart as shown:

This chart shows very clearly that those features should be included. If a feature is in the yellow area------choose them, and the-----in the rest of the region will choose it next time if you're lucky. (Of course, if things change, it's a good idea to reassess your initial rating in a timely manner)

Identify killer features

Read here, you've got some visual guidance on how to identify killer features.

Notice the green point in the upper-right corner of the picture, which represents nearly 100% of the customer's use of the feature, and they rated the value of the feature to 10 points. To be sure, this is the most worthy feature called "Killer function."

Of course, this feature is unlikely to make you see it often. In those cases, features that are close to the perfect rating can actually become killer functions.

Finally, notice the red dot at the bottom of the left corner, this level of functionality, like a startup killer, so make sure you never let this feature appear in your project.