So you want to build an app. You have a long list of incredible features that you want to include, and you’ve got the financials to do so. You might be thinking:
Let’s build every feature out and release it to the world, yeah?
You’re probably thinking that without the entire feature set you’ve dreamt up, nobody will use the app, it won’t be complete, or it won’t succeed.
You’re not alone…
More often than not, clients come to us with a long laundry list of features they would like to release in the first version of the app. But usually, their apps could be released with ⅓ of those features (or less) and achieve the same level of success. This may sound a little strange, I know.
You’re thinking, I NEED this cool feature for the app to be successful.
But let me give you this scenario:
You build an incredible app—let’s say it takes 4-6 months to complete every desired feature of the app. You believe it’s now in its finished state, so it’s time to share your app with the world.
People begin to download it.
You start looking at the analytics.
Real user feedback begins rolling in.
Here are two things that are very likely to happen:
- After looking at the analytics, you realize a few features that had taken months to complete are not being used by most of the people on your app.
- Users start asking either for a new feature you hadn’t thought of, or changes to existing features in the app—or even worse, they start complaining about some of those features you spent months on.
Spending money on features that nobody wants is not a good feeling, and having to go back to the drawing board because you picked the wrong features can be just as painful. So, how can this be avoided? In this post, I’ll share some of the lessons that I’ve learned over the last few years as a Product Designer at MindSea, and how you can reduce the likelihood of falling into this trap.
1. Keep It Lean
I can’t stress this one enough.
For your first version of the app, you need to keep it lean. Users love a simple app that has a clear, core function. The first version of Instagram didn’t have video… It didn’t have stories… It didn’t have “close friends” and it didn’t have DMs.
You want to avoid creating a “Swiss army knife app.”
If users don’t know the core functionality of an app, you have too many features. Humans like choices, but we have a hard time deciding or navigating if we are offered too many options. That’s certainly true of apps and their features.
So, how do you know you’ve achieved the core features of the app?
Come up with an app definition statement.
An app definition statement is a concise, concrete declaration of an app’s main purpose. The statement helps your team align on the main purpose of the app throughout the build. Once the app does what the statement says, get that baby out there and start testing it. For more information on how to deliver a lean product, I’d recommend reading “The Lean Startup.”
2. Test Early And Often
Ideally, you want to test a prototype of your app before you even start writing a single line of code. Here’s some more information about User Testing: What It Is, How To Do It and Why It Matters. This simple step in the process will help you de-risk your app development process and increase the likelihood that you build an experience people want.
The moment you have the core features of the app identified and incorporated in your prototype, get people testing it—whether it’s a private beta, or the first app store release. The main goal is to get your app into the hands of real people so that you can start analyzing how they are using it every day.
3. Let The User Feedback Define Your Feature Roadmap
If you are assuming what your users want without asking them, you’re probably going to fail.
I know that sounds harsh, but it’s true.
Assumptions are things we take for granted as being true, without evidence or proof.
Verbalize the major assumptions you and the team are making about your product and your audience. This exercise allows you to take a step back and better understand the people you’re trying to serve.
Assumptions can be a dangerous thing, so try and validate those assumptions as soon as possible. You can validate your assumptions by user testing the earliest version of your app, or, even better, a prototype. It’s going to save you a pile of money in the long run instead of developing features that people may not want or need. It’s amazing what your product can turn into when you let users take the reins, and they’ll be more loyal because of it.
As mentioned before, take a look at the evolution of Instagram:
So much change. But also so much success…
Instagram understood what their audience wanted and made UX and feature adjustments that helped the app stand out. After studying their own customer reviews and looking to Snapchat to see what features their users loved, Instagram embraced iteration and improvement.
4. Define Clear KPIs
And finally, along with your app definition statement, you should have clear key performance indicators to define what success will look like for your app. A lot of people go into launching an app without having clear goals identified and key performance indicators to guide their decisions.
You might initially think that every app developer has one goal:
More users.
But in some cases you’re not trying to reach mass scale. Sometimes your goal is simply to provide an additional layer of service. Sometimes an app is just an add-on to an existing offering. And sometimes you only need 10 people to use an app for it to be a success.
In these cases, the KPIs will obviously be different. You might care more about retention, daily usage or actions taken. Every app is different—which is why identifying your KPIs early is so important for measuring success.
Wrapping Things Up
If you’re looking to build an app and aren’t sure which features you should keep and which you should scrap, start with research. Talk to potential customers. Show them a working prototype. Get their feedback and use that to guide your approach.
And if all of that sounds intimidating—get in touch! We’d be happy to talk to you about our Blueprint process and how we uncover these answers and insights.
