Build Usage, Not Features

At Akrity, we follow three core principles for every project:

1. Don’t build what you don’t need
2. Build what you need really well
3. Build usage, not features

In earlier articles, we discussed the first two principles: Don’t build what you don’t need, and Build what you need really well.

In this article, we take a look at our third principle: Build usage, not features.

Companies that go on to become successful know this quite intuitively.

At times, product owners work to satisfy two groups of people: the users and the client. Why would anyone build a product with too many features? Well, either, they are not sure what their user really wants, or the client forces the product manager to build too many features, thinking that is what will make a product successful.

As we’ve seen time and again, a feature-heavy product simply does not work.

Why not? Well, there are a couple of pretty obvious reasons:

• More often than not, a product needs to solve ONE burning problem that the user has. With too many features, product managers are giving the user features they probably don’t need, at the same time making their application clunky and cluttered.
• When they opt for too many features, chances are that they are not quite sure of what their user really wants. Well, if that isn’t clear, what is it that they are even building?
• Considerable resources are being spent on building these ‘extra’ features, drawing attention away from the ONE problem they should focus on solving. Also, if you notice, it violates the first two principles we keep talking about.

This is a mistake even the big boys make!

Take Amazon for example.

You open their app or website and are bombarded by a hundred different options, button, flashing images. Do this small exercise: just stare at the screen for a bit and ask yourself honestly: how many features do you actually use?

Bet it’s under 20 percent of the features, and that’s to be safe.

But here’s the thing: what did Amazon do to become successful? They just sold books. One burning problem. One superb solution. They did not have these features when they started off. It was a much simpler, much sparse, much lighter application that brought them all the success.

So, a lesson we can take from this we can take is that instead of following what the successful people are doing now, it’s best to replicate what they did to become successful. The answer to that will always be simple.

Onto something else that you might find interesting.

Have you heard of the User Happiness Curve? If not, here’s a representation:

As is clear from the graph, studies have shown that after a user is happy with a certain number of features, any extra features actually turn them off.

Now, since we know users are happy if your product solves that one burning problem that’s been bothering them, users are happy, isn’t it safe to say any added features that don’t have any use just make things worse?

Of course, it is.

So, how do you know which features are needed and which are ‘extra’?

Simple, build usage, not features. Our third principle solves that problem.

See, these principles are like a compass. When in doubt, all you do is look them up, and you will see the solution emerge.

They may seem quite simple, but they work…just like a good software product should be.