So… You have a brilliant app idea that you are ecstatic about. You can’t go to sleep at night because you have too many incredible visions of the future rushing through your head. Your spouse is getting sick of hearing your endless recitations of how cool it will be once your vision is given to the world and you’re ready to begin executing.

You begin asking people what they want in the app. Your mom said to add selfies, your uncle said to have a dashboard, the girl on the subway said they want the option of pink buttons… and on and on.

Everyone has an opinion, and everyone thinks they are the expert. You add their requests into your design until you’re sure it’ll please everyone.

So you think to yourself, “Now that I’ve got this all laid out, let’s get this puppy developed.”

WRONG!

From our experience, this is the number one mistake that people make when building an app for the first time, they try to build too many features that are unimportant instead of doing the hard work to prioritize the features that are.

This is exactly the path that people take when they are going to spend a bunch of money building an app that no one wants to use. Wait? Why?! Didn’t you just spend all this time figuring out exactly what all the users want?

No. Not really. You see, despite what users tell you they don’t want features, they want simple solutions to challenging problems. If you simply take the aggregate feedback of all the people who have an opinion and turn it into an app, the result is a mess, when what they really want most is just something that solves their problem.

For instance, pre-Uber, had you asked people what they wanted in a taxi cab app they might have said, “I want to be able to call drivers and tell them I’m here” or “I want to be able to schedule a taxi cab pick up time and place.” But if your planning scheme was based on their feature requests you’d have simply built an app that was marginally better than what currently existed.

Uber & Lyft were able to transform the taxi industry because they were looking at the problem space (the customer problem that needs to be addressed) first, “How do I get from one place to another efficiently when I don’t have a car?” instead of the solution space (the specific implementation to address the problem), “How do we solve the problem?”

So what does it matter if we build a few extra features, you say?

1 - Your users have short attention spans:

Today’s consumer gives you an extremely short time slot to grab their attention, (clocking in at around 8.25 seconds, just shy of a goldfish.) You have to show them that you are the solution problem, and then get them to their solution as fast as possible, or they’ll be off in the app store searching for your competition.

Every additional form, every extra button adds friction and cognitive load, so by having extraneous features you run the risk of muddying the main purpose of the app.

2 - The longer you take to develop your product, the longer the delay of your feedback loop:

Everything before the app is in the app stores is like playing house when you’re a kid, in the playhouse, there’s no mortgage or marital issues, similarly while your app is still a prototype everything seems perfect, but once it hits reality you get real true feedback on what works and what doesn’t. So the goal with the first version of the app is to only build what you are absolutely confident in, and nothing more, because reality is the best teacher.

3 - Your budget is limited:

Maybe your project is well funded, maybe you’re working on a shoestring budget, either way, if you build extraneous features in the app that you later find are not necessary you are paying for them twice (once to have them put in, and once to have the code ripped back out of the app.)

Know thy user

The fundamental rule for prioritizing which features to build is to know thy user. And while we could write volumes of what it means to understand your user, the main point is to get out of the building and sit down with potential customers and get feedback.

It’s easy to feel like you understand user's needs and desires, especially when you consider yourself to be in the target demographic, but nothing can beat going knee to knee and hearing it from their own lips.

When you set up these meetings the goal is to discover how the potential user views the problem, from their eyes and in their words.

You want to not only validate that you’ve nailed a problem that they care about solving, but also that your solution is one they would be easily willing to pay for.

If you were building a taxi replacement app, your interview could look something like this:

• When you need to get a taxi, what is your usual process? It is best to ask open-ended questions so you don’t tell them what problem you want them to bring up.
• What do you use to find a taxi? This question gives you insight into who your competitors are, even if they are not direct competitors. For instance, you may be competing with just waving a taxi cab down.
• What do you like about the process? (It is important to know what the current solution does well so you can focus on differentiating in other areas)
• What do you dislike about the process?
• We’re thinking about building an app where you press a button and a ride appears, what would you need to know in order to feel comfortable using a service like that? It’s important to put questions with your solution specifics towards the end of the survey so that you get objective answers before.
• How much would you be willing to pay for such a service?

Once you’ve completed a number of in-depth interviews (obviously the more you do the more the data set will likely reflect reality) then it is time to build a prototype.

The best way to do designs at the beginning is just freehand on a whiteboard designing out an app that you think will solve the user’s problems, then going back to them and getting feedback.

Is this time-intensive? Yep. Is it worth it? Absolutely. Not only is it invaluable for you as the business owner to have first-hand experience with your users, but you can save yourself a ton of headaches down the road.

Measure twice, cut once

You want to know some advice that basically no one ever takes but should? It comes from a conversation that Brian Chesky the founder of Airbnb had with Reid Hoffman the founder of LinkedIn:

Brian Said:

“We had a saying that you would do everything by hand until it was painful. So Joe and I would photograph homes until it was painful — then we would get photographers. Then we would manage them with spreadsheets until it was painful — then we got interns… Then we would automate the tools to make the interns more efficient… And then eventually, our system does everything. We build a system where now the host comes, they press a button, it alerts our system, which goes to a dispatch of photographers — so it’s all managed through technology. They get the job, they market through an app that we built, and then payment happens. The whole thing is automated now.”

Reid added:

“Note how they gradually worked out a solution. They didn’t guess at what users wanted. They reacted to what users asked for. Then they met the demand through a piecemeal process… [This] gives your team the inspiration and urgency to build the features that users really want.”

By doing everything by hand for as long as possible it allows you to be able to understand every facet of a problem before you lay down code to solve it. By enduring a little bit of pain upfront, you save yourself a lot of frustration down the road on app development.

Know your business model

One of the biggest determinants of what should be built is what your long-term business model plans are. The first question is when do you want to monetize? If you are focusing on monetizing from the get-go the bar is pretty high, and you’ll have to do more work to make your users comfortable with the process.

If it’s freemium, are you just building the free part of the app first and then adding the rest later? Or does it need to be there from the get-go?

Is it completely free with ads? Then perhaps you need to think more about the virality of the app, should there be something built into the app that incentivizes people to share?

The other part of knowing your business model is doing the math, this should be done well before you even start the process of building your app.

Under this business model, how many users will you need to convert to make it profitable? What will be your expenses? What do you estimate the conversion rate to be? How many users will you need in total? Do you have enough money in the bank to play that kind of game?

Your app in your head is likely to have many of the wrong features and if you build it you’ll likely be disappointed by the response of your users.

The way to prevent this from happening is to sit down and get to know the needs/problems of your users really well. Then to design an app based on solving their needs in an ideal way. And then doing the math to understand what a financial victory would look like.

If you’re considering building app software or SaaS product for your company and want help, we’d love to chat.