Before You Build Another Feature

Before You Build Another Feature

Do you remember Google+? One of Google's bets that was supposed to get them into social networking business?

From the very beginning it included tons of features - status updates, "circles", trending topics stream, video chats, events, games, pages for businesses. Everything you could ever expect a social network to have.

But despite covering all possible aspects, it failed to get social networking right. A lot of users joined the service only because it was integrated with other Google services.

Finally, after 4 years of operating, most of the service was scrapped as a part of a major redesign.

This experiment wasn't cheap - it took a few years, $500M in cash and hundreds of engineers to build. And all that effort didn't pay off.

You Cannot Afford Moonshots

It happens all the time. People keep building useless features and other people don't use them.

Unless you're Google, you probably don't have enough money to make bets of this size. But you still may be making smaller ones, without even noticing. Have you ever built a feature based on your gut feeling? Hearing "Yes, they'll probably need that." in your head.

Software Engineer's work costs over $10,000/mo. Make a team of three, add designers, testers and marketers and a three-month long feature suddenly turns into $100,000. That'd better be a good one.

Fortunately, there are a few questions you can ask to yourself before building them. They will not only protect you from wasting your money, but also they will help you build better products.

Do You Know What Problem You're Trying to Solve?

Let's start with the why.

In order to build a feature that people want to use, you need to know which of their problems it will solve. Just by defining that, you'll quickly discard ideas for functionalities that don't serve any purpose.

And if they don't - well, maybe there's a better use for your time.

Besides that, focusing on the problem will also save you from building unnecessary tweaks.

For example, think about user profiles and personalizing them. When we consider software that helps people communicate, ability to upload a photo is a must-have.
If you look at your slack channel, seeing people's faces along with their words makes it easier to recognize who wrote what.

On the other hand, implementing the same feature in Quickbooks would be waste of time. It may be tempting to make accounting software more personal by letting users put their photos in it, but would that help with organizing invoices? Probably not.

By keeping the problem in mind while designing features you'll narrow your focus to what's really important.

Does Your Data Say You Should Build It?

As soon as you define the problem, make sure you have data that indicates that it really exists.

It may come from various sources, depending on what's available to you.

You may see a lot of requests for this (or similar) feature sent to your Zendesk. You may also notice that a lot of customers mention a particular gap in your product when they terminate their contracts.

If people keep talking about it, it's definitely worth to look into it. Those people will also be the best group to test the newly built feature with. They need it and they took the effort to tell you about it. It means that they care.

Another good source of insights are analytics tools that you can hook into your app. Reports in Google Analytics, Kissmetrics or a custom reporting built especially for you will give you a lot of information on how people use your product.

If you're adding new features on top of existing ones, take a look at at their analytics and check if they're popular enough to invest money in improving them.

When you're thinking about automating tasks that people at your company do manually, you can first check if that will save enough of their time for the development work to pay off.

Sometimes it's just cheaper to do things manually. As an example, Uber took that approach with deleting user accounts.

For years, if you wanted to delete your Uber account, you had to submit a request to their support team.
They've just automated the whole process once a lot of people started doing that and it became painful to do it by hand.

Is It the Bare Minimum?

Once you know that the problem is worth solving, think what's the minimal solution for it. It's tempting to spend a lot of time building numerous features before showing the product to the outside world.

But that's gambling, hidden under the cover of being productive. You're not getting any outside feedback on your product. As the clock ticks, you're putting more and more money into it yet there's no way to say if that's what people need.

What would happen if instead of building everything, you'd focus on the most important thing? You'll be able to build the product faster and ship it. You'll be able to get feedback early on and change direction if necessary.

Just look at how Apple built their products ten years ago.

When Steve Jobs presented the first iPhone, it lacked a lot of features that most phones already had.
It had a terrible 2 megapixel camera (Nokia's high-end phones offered 5 at the time). If you wanted to use 3-rd party "apps", they had to be browser based. Which wasn't the most pleasant experience considering that the phone didn't have 3G connectivity.
The first two iOS versions didn't even have the copy-paste feature, not to mention multitasking capabilities.

With the first iPhone, Apple figured touch interface just right (photo: Apple)

Despite missing a lot of features, they were able to establish a strong brand that for almost a decade led the smartphone industry.

How?

The first iteration brought a breakthrough touch-based interface, which was its most important feature.
Once it's been tested and widely approved by early users, they moved forward. Next generation of iPhones brought faster internet and support for custom apps. Building less at a time but in a well-thought manner, they were able to catch up with competition and later outmatch them.

What's interesting here is that if you start with the core features, you'll find people who'll be interesting in using the early versions. They won't be mad at you for making their lives a bit easier, even if the product misses a lot of functionality.

Others won't use it yet. They'll have a chance to try it and let you know what's important for them. Once next iterations of your product fill these gaps, you'll be able to sell to them as well.

Gambling is for Losers, Build Smartly

There's always a bit of risk in introducing new products to the market. You cannot tell for sure if a larger audience will like it.

That said, it's still possible to mitigate this risk by using the right tools. The most important one is focusing on the problem and the user. Then, there's plenty of software that will help you gather data and estimate whether the problem is worth spending time on. And finally, focusing on smaller things will help you get feedback faster and build features the right way.

Build smaller things, but build them better.

Did you like this post?

I write about building software that makes people's lives easier.
Sign up below and I'll let you know when I publish a new post.