The Smartest Way Of Building Mobile Apps – Lean App Development
What is the fastest and most cost effective way of building mobile applications in 2014?
To some this may be new, to others this is a century old. But in the world of successful startups such as Dropbox, Instagram and Google this is the norm.
What exactly are we talking about here?
The Lean App Development Methodology
Taking the original Lean Startup Method, or the Toyota Lean Manufacturing method, we’ve crafted our own approach to developing mobile applications with the same principals:
The Lean Startup Method for Mobile App Development. Or as I like to call it – The Lean App Development Method.
The lean app development methodology is a method used for building and launching brand new applications quickly and at the lowest possible cost – not cheaply, we don’t want cheap product. But cost-effectively.
It’s an approach built around a strong emphasis on risk mitigation and performance optimisation. The aim is to take your application to market quickly, test it and find out what’s wrong with it as quickly as possible.
Where most new app developers go wrong
Most app developers and even app development companies, entrepreneurs and certainly enterprises launch large convoluted systems into the market place with very little guarantee of success.
How do I know? Because I deal with it every day…
Here’s what happens:
The ‘ideas-people’ get together. They throw all their best concepts on the table. Then they strip out the ones that are border-lining on ‘irrelevant’ and keep the rest.
Next, they send their requirements out to a number of app development companies like Buzinga. They want multi-platform, iOS and Android, packed with features and complete with a clearly thought out monetisation model.
Then the quotes come in – $75,000 – $95,000… The agreement is signed and the project goes ahead. Everyone’s excited…
A few months later the application hits the App Store. Huge marketing budgets are deployed and the downloads start flowing in! Now everyone is REALLY excited.
But sure enough the download figures start to drop. First it’s subtle, but after a few days we’re down to 20-30 downloads per day. Eventually there’s barely a trickle…
Everyone’s confused. The project went bust.
What went wrong?
Simple.
People downloaded the app. They liked the idea of the app, but it was too hard to use. Or it didn’t do what the users wanted. Or the monetisation model got in the way of the experience. Or … the list goes on.
Here’s what actually went wrong:
The concept was never validated. Big budgets were spent on building an app but no thought was actually put into the development strategy or risk management.
There’s a word that describes the act of waging money on an non-validated outcome. It’s called gambling. And believe me, the odds are NOT in your favour. About 100 to 1. How do you like those odds?
Would you like to know a smarter way of building apps?
If you nodded your head, please continue reading. You’re going to love this.
The Objective
The overarching goal here is to LEARN.
- Learn how to satisfy our users.
- Learn how to monetise our user base.
- Learn how to promote our product.
- Learn how to design a profitable business model.
How do we do that?
Let’s dig down…
Your First Business Objective
No, world domination is not your first business objective. That would be number 54 or 55…
The first business objective is ALWAYS to ‘validate the concept’. Or in other words; to test your assumptions.
In the process of identifying your application business model you will have made certain assumption about your target-audience, competitive landscape, user adoption, etc. for it to make sense.
Let’s not write these assumptions off as facts but rather aim to validate them first.
Once the concept has been validated you can confidently invest more time/capitol into the business concept.
What assumptions have you made?
Write-out a brief about your app idea and list all assumptions that you have made.
“Assumption: A thing that is accepted as true or as certain to happen, without proof.” – Google
If you’re making decisions without proof…you’re gambling. Here are some common assumptions:
- The problem that my application solves is a common one – related to market size
- People will use an app to solve this problem – related to the medium
- My target audience is X – relating to the target audience
- This business model is monetisable – relating to the monetisation strategy
- People will make the decision to do X – relating to user behaviour
- Etc.
As you could imagine, the list of assumptions is endless. And the assumptions are almost always unique to the individual application.
Where most app developers, app development companies, tech-entrepreneurs and enterprises go wrong is they never set out to test their assumptions.
Deploying an MVP with an aim to test these assumptions means you can quickly tick off the boxes and validate the concept. If the ‘boxes can’t be ticked’ and your assumptions are WRONG then that’s a good thing. Don’t be disheartened. I mean wouldn’t you rather know upfront that your business is going to fail, instead of finding out 6 months later when you’re $75k+ out of pocket?
No need to answer that question…
So what is an MVP?
The MVP (Minimum Viable Product)
An MVP is the absolute bare-bones, built with the single purpose of testing your assumptions.
It’s a strategically stripped down version of your ultimate application. Like a test pilot. Dip your toe in the water to test the temperature before jumping in.
Though I can’t actually tell you what your MVP should look like, because every application and business model is unique. However, your MVP should be designed with the bare minimum features/functions required to test the assumptions we discussed above.
Anything outside of that IS NOT AN MVP and should be placed into the ‘Future Ideas List’. This is important.
Building the MVP
Ok, let’s assume you’ve designed the basic concept – your MVP. What now? How do you use it to test your assumptions?
There are a couple of preparations you need to make before you actually build out your application. First of all, you need to get clear on what metrics you’re going to measure.
See also: How To Measure The Success Of An App
Build these out into a spreadsheet so that you can easily capture this information using a mobile app analytic tool like Google Analytics, etc. We need to get an accurate reading on the user adoption and campaign performance.
Some important considerations for where to launch your MVP might come out of learning about The Secret Formula To Building A Minimum Viable Tech Product.
Once your application is built (should take no longer than 3-5 months) it’s time to launch your app and collect feedback. Here’s how we do it:
Build, Measure, Learn, Feedback Loop
The Build, Measure, Learn, feedback loop was introduced in the Toyota Lean Manufacturing Methodology. The idea is to build out a basic version of the product (MVP) or a particular feature, then measure it’s adoption and performance based on feedback, then lastly, learn what to do better/differently based on the feedback.
Build
Start with your assumptions. Set an experiment with no more than two outcomes. Either: YES – It’s validated; or NO – it’s not validated. Build out your MVP.
Remember, no frills, no bells, and absolutely no whistles.
Measure
Prepare a spreadsheet of metrics you need to measure to accurately validate (or unvalidate) your assumptions.
Implement feedback mechanics (such as customer feedback forms, Google Analytics, focus groups, etc.) to make sure you get an accurate reading of qualitative and quantitative data. This is important because if you’re feedback mechanics aren’t rigged properly then you’re not going to learn anything from it. At the end of the day app development is about learning, right. And if you don’t learn from these experiments then you’re failing.
Learn
What did you learn from this experiment. Remember, the result can only be one of two possible outcomes.
Rinse and Repeat
What next?
Start again. Set another objective – any other assumptions you might have made in your business model, or any assumptions you’re yet to test. Alternatively, if your concept has been validated from your experiments and you’re ready to implement a new feature, simply start again:
1. What assumptions have you made about this feature?
2. How will you test this assumption – MVP?
3. Test, Measure, Learn.
Rinse and repeat.
Do you have any questions about this concept? Please share below!
Latest posts by Logan Merrick (see all)
- Ep 18: Collective Campus’ CEO on Intrapreneurship and Corporate Innovation - December 20, 2016
- 50 User Engagement Strategies For Planning Memorable Mobile Experiences - December 19, 2016
- Latest Data: App Monetisation Trends And Drivers 2015-2020 - November 25, 2016
