All Blog Posts

Building Product Features Users Will Actually Use

Building Product Features Users Will Actually Use

When you’re building a product, feature ideas will come from everyone—customers, business partners, your development team, and others.

You can’t (and shouldn’t) use them all. So how do you decide which ones to keep?

Here are five steps to help you make the final cut:

1. Default to no

Think of features as the enemy. Every time a feature comes up, default to “no,” limit your excitement, and make it prove its value.

Features are guilty until proven innocent. Verify the feature provides value, think through the idea, and talk about it with your team.

Make the person requesting it fight for it. Then try to talk them out of it. If it’s truly worth your time and money to build, it will be easy to prove its value.

2. Measure and define success

When implementing a feature, decide ahead of time what you’re going to measure. This could be anything, from an increase in session time to an increase in task completion.

Then determine how you’ll define success. For example: By implementing feature X, you’ll increase total session times by 20%.

3. Prototype and test

Start by sketching out your idea before you write a single line of code. This allows you to fully think though the idea, and quickly and cheaply change it as needed. (People usually find that their solution is wrong the first time.) It doesn’t need to be fancy, but it should be enough to be a good representation to users.

Round up some real users—people who currently do or would use your product. The point is to get honest feedback. Your mom (who loves everything you do) or your best friend (who agrees with everything you say) aren’t your best options.

It should be someone who has context of your product. Present them with the problem, let them use your solution, and gather feedback. Repeat and iterate until you receive positive feedback.

4. Build and A/B test

Once you’re comfortable with the solution, you can start building out the feature. However, before you implement it to your entire user base, do a partial rollout—release it to a small percentage of your users, gather more feedback, and compare that segment to your control.

5. Release it to your entire user base

Remember, the feature still hasn’t proven its value. Continue to measure and collect feedback as users interact with the new feature.

Compare your metrics to your benchmark. Is it what you were expecting? Are people using it? Does it provide the value you hoped, or is just another link in the navigation that’s cluttering up the interface? If it’s not improving your metrics, it’s not providing value and should be removed.

When it comes to adding features to your product, the question usually isn’t “can we add it?,” it’s “should we add it?” Going though this process will make it easier to decide which features will add value and which ones are just wasting your time and money.