Why MOST App Development Projects Fail: Overbuilding!

Imagine realizing half of your app’s  core features are completely useless. AFTER launching. Wouldn’t it be nice to have known that beforehand?

It’s a common problem - business owners jump into app development without clarity of core features. So they think ALL features are core features. And by they, I mean you Truth is with any app, only a few things matter.

Nowadays, my team and I sit down with  new clients to determine their app’s core features. And if we can’t align by  the end, then it’s a friendly sayonara. In this video, I’ll be walking you through  this process - it’s just four steps.

By the end you will have  clarity this is all you need. And if you need convincing, stick to the  end where I share one of my most painful learning experiences early on in my career A client insisted on tons of features from the start, it all went to shit, and 4 years later  I still have an unpaid invoice for $20,000. Let’s save the trauma dumping  for later and get straight to… A user persona is a fictional  representation of your ideal customer.

At Upstack Studio we give them a  name and combine our own 1st hand research and 2nd hand information  to create a profile that includes: Demographics: Age, gender, occupation, education Background: Work experience, lifestyle, and personal interests Goals: What the user is trying to achieve with your product or service Pain points: Obstacles they face in achieving their goals Tech-savviness, and: How they interact with tech and what influences their decisions Motivations: What drives their decisions Remember the same person  can have multiple personas. A woman could be a mother, a business  owner, and a yoga enthusiast - three separate user personas each with their  own goals, pain points, and motivations. Which of her personas are you selling to?

The more specific you are, the better People ask me - Adrian, can  I have TWO user personas? And I go - TWO user personas? Absolutely not!

Then I slap them in the face like that Batman and Robin meme. Then I’m like oh wait, you CAN have two personas - my bad. Look, you can have THREE user personas.

You can have four. You can have as many as you think is necessary. But there must be one primary persona  representing the biggest pool of potential users.

Also subscribe and leave a like. Don’t make me go Batman on you with my hand of justice. Here’s a sample user persona we came up with once for a guy called Chad.

I’ll link to it in the description if you want to read it in more detail, and there’s  a blank editable version for you to use for your own personas. Once you have it, you go to Step 2: Finding Their Most Urgent Problems Zoom in on the pain point of your user persona. Some developers include it as a part  of the overall persona document.

My team likes to give it a dedicated section. Either one works. In both cases, the goal is to identify  the most urgent problems preventing this persona from reaching a goal.

The goal your app will ultimately solve. Try to solve. We start by listing down all the problems they face.

For the user persona before, this was one problem we identified. Then we keep going - what other issues are they facing within the scope of this goal? List them all down.

When you feel there’s nothing more,  shortlist the top three most urgent. Don’t think of it as if I solve these  problems my persona will for sure use my app. It’s more like if solving these problems  doesn’t convince my persona, nothing will.

Why three? Because the more problems you need to solve, the less attention each receives. Solving ONE problem PERFECTLY will hook users way more than kind of solving twenty problems.

I want you to focus on solving problems REALLY well - and three is in my  opinion, the limit for most people. Once you’re done here, it’s time for Step 3: Defining YOUR Value Proposition By now you know who you want to help  and what you think they need help with. Time to describe how your app is going to help.

For Chad, this is what we ended up going with. Simpler pain points can be solved with one  value proposition - that’s what we did here. But more complex problems could  need a bundle of propositions.

And it’s always a good idea - in fact I’d  say mandatory - to do competitor research. This is when you identify market gaps or  unique selling points your solution offers. It doesn’t have to be groundbreaking  but that certainly doesn’t hurt.

Most times, it’s as simple as existing solutions  being too slow, too expensive, too unreliable. Or they don’t offer enough variety, maybe  their customer service takes seven ice ages. Check their google and apple store reviews.

Check their socials. Ask people on Reddit. Every successful product has compromises a competitor can exploit.

Once again, write down all the value propositions your app can provide, making sure the three pain  points you shortlisted are fully addressed. Right now, you should be in  a position where you know: Who you want to sell to What problems they face, and What value propositions your app must offer Now, time to give yourself a lobotomy. Step 4: Brain Dump!

The brain dump has two parts. In the first, you list out all the  features your app needs to have. ALL of them.

Don’t ask questions like will this be too expensive, or is this practical. We have time to be rational later. For now, we brain dump.

It’s not unusual for a Brain dump session to produce hundreds of features. Some people have been building an app in their heads for years, so it’s like unclogging a  blocked toilet bowl and everything comes gushing out - remember that hippo farting video? I say this with love: It’s gonna be like that at first.

So let it all out. Let it permeate the atmosphere pollute the air and give everyone in your  vicinity an eye infection. Now go for a five minute  break to clear your mind.

Hug your kids, if you don’t have  kids, hug someone else’s kids. If they get mad, say you’re developing  an app - they’ll understand. Now come back and you have  shit all over the place.

Underneath that shit are nuggets of gold. To find them, you screen every feature with three questions: If I remove this, does my app still solve the persona’s main problem? If I remove this, does the app still feature?

Did I list this down just  because I think it’s cool? You’ll find a lot of features  are actually unnecessary. In fact, a lot of them are there  because you saw it on another app and you got a bad case of the FOMO.

You’ve become a chronic fomosexual. Well I’m here to spread fomophobia. I once had a brain dump session where the business owners listed 211 features.

Developing it would have paid for my retirement. You’d think it was an app for rocket science,  but it was just a recruitment marketplace. We crossed out features one by  one and ended up with 103.

Still a lot. - cut compared to 211, a lot less. It also meant much lower development costs and shorter development time, so  they could go to market faster.

And that’s what all of YOU  stand to gain from doing this. However many core features you think are needed, imagine realizing half of them are not  necessary before you commit to development. You spend less, get an MVP out  faster, and it’s just as good.

Besides, it’s only when real users use your app  that you REALLY learn what the key features are. You might think oh, then why bother with  the four steps if it’s gonna change anyway? Launching an MVP will involve iterations no  matter what, but there’s levels to this.

if you’ve done your homework,  changes will be minimal. If you just spam features, the changes  will be more drastic, more expensive, more time-consuming, and it's much  more likely the project will stall. It’s also more likely you’ll run out of money  halfway, like what happened to my ex-clients.

Editor, cue nostalgic sound effects. It was 5 years ago. They got in touch with me and my team to build  them a location-focused job-matching platform.

And their idea of an MVP was very rigid. They wanted a lot of features that our team felt didn’t really have to be there yet. Their USP was location-first job matching, so my team would’ve liked to  launch an MVP with just that.

But the client insisted on extra stuff like  paid resume unlocking features for recruiters. They were convinced that unless their MVP had  a million features, users wouldn’t come back. Problem was they also had a deadline.

You can’t have it both ways - you cut down on features, or you push back the deadline. They pushed back the deadline. In the meantime, their existing business, which  was funding the app, suffered internal issues and could no longer pay for development.

If they had gone with our suggestions, it would have cost them about USD35,000 and  they would have had an app launched and possibly generating revenue if the idea was good. Instead, development costs had climbed to USD70,000 and the app still wasn’t launch-ready. I invoiced them for the latest code base and they just said no, we can’t pay.

I still have the code base today - completely useless. Don’t be like them. Once you know your app’s  core features and features, the natural next step is creating an MVP.

You could build a prototype app if you have the funds or the expertise. But if you have neither, there are actually a lot of different types of MVPs. You have landing page MVPs, newsletter MVPs, and I kid you not, a Wizard of Oz MVP.

I cover all those and more types of MVPs in this video, complete with successful  examples, and I recommend you check it out so you have a clear idea of how to take  your app idea forward when the time comes. It’s not just about building the app,  marketing is as important if not more so. If you found this video useful, please subscribe  and leave a like, and let's check out some MVPs.