Think your app idea has what it takes to be the next Instagram?
Think again. As of January 2013 there were 775,000 apps in the iOS app store, yet nearly 60% of developers report they never broke even on their development costs. Even worse, almost 70% report their most successful app never made more than $5,000. Ouch.
Breakout successes like Instagram don’t “just happen” without customer feedback and insights.
Judging by the apps in the iOS app store, my guess is, the majority of unsuccessful developers aren’t checking with their potential customers to see if their app is something people actually want.
Not testing is like going to a new restaurant and expecting the waiter to deliver a delicious meal without checking the menu or having a conversation about your food preferences. It just doesn’t work.
The idea is that by involving your customers during the different phases of app development, you’ll create something people are really going to want and can be excited about.
There’s a lot of ground to cover, so let’s jump right in. If you haven’t already, click here to get a copy of the Validation Board to fill in as we walk through how it works.
The Validation Board for Mobile Development
On the top half of The Validation board, we’re hypothesizing who your target customers are and the pain they’re experiencing.
Try not to over think this. When you work on the top half of the board you want to hypothesize about your customers and problems as quickly as possible.
- Use 5 or less words
- Write all caps
- Take no more than 10 minutes to define your customers & problems
The reason you don’t want to over think this process is, in all likelyhood one of your hypothesis will be invalidated. It’s not bad though.
Better for it to happen when you’re just dealing with sticky notes than a launch into the app store.
Your customer hypothesis is the group of people with a common pain you’re trying to solve.
It’s important that when defining your customer, you’re not looking at the mass-market opportunity, but rather who your product’s early adopters will be.
For Instagram this eventually became “Casual iPhone Photographers.” People who still care about what their pictures look like, even if they were just taken on the iPhone.
Focusing on a very specific group like this is important because these people will be the ones to tell you what you need to know to build something awesome.
It’s this audience that will give you valuable feedback along the way and help you to define which features to include, and which are unnecessary.
Having this feedback directly impacts your wallet during the development process. Knowing what features your users want and will want allows you to build your app in a way where these features can be easily incorporated in future iterations vs having to recode the app from the ground up every time you want to add something new.
The problem hypothesis is all about how your customer defines the problem in their own words.
The idea is that defining the problem in your customer’s words, your app becomes an answer, rather than just one of many solutions.
According to Instagram’s first blog post, there were three main problems.
- “My mobile photos look lame”
- “It’s a pain to share to all the friends I care about”
- “Photos take forever to upload, and viewing them is slow”
Notice they didn’t write “iPhone doesn’t have color filters.” or “iPhone doesn’t utilize social network APIs” or “iPhone doesn’t use expedited cloud sharing blah blah blah”.
The solution hypothesis is what you think the core functionality of your app should be.
The truth is, even though you may have a great idea in the beginning, you don’t really have a solution until you’ve validated the problem hypothesis.
Be sure your hypothesis about your customer’s problem is validated or true, otherwise you’ll build something nobody cares about.
It’s important you make this distinction early on, otherwise you’ll drive yourself crazy trying to push your solution rather than adjusting it to fix real problems.
Like a scientist, you have to design experiments to validate or invalidate your customer and problem hypothesis.
The bottom half of the validation board is where you’ll design experiments & keep track of your core assumptions about your customers and problems.
It’s this process where you learn the most about your potential customers & discover if what you’re planning on building is really something they want or need.
An assumption are things that you as the app designer believe to be a fact about your customers and their problem.
The riskiest assumption is one that, if it were invalidated through experimentation, would cause your team to pivot.
The idea is that by putting all of these on paper will give you a well rounded view of your customer’s problems before you ever bring these assumptions to your customers.
For Instagram, the riskiest assumption with their original app Burbn was that people wanted a location based photo sharing social network. Unfortunately for them it took a year of development and stealth launch, before they realized the idea wasn’t exactly something people wanted. If the pivot proved unsuccessful, would have cost them $500,000 in seed money they raised from their first VC round.
Minimum Success Criteria
To make sure you don’t drive yourself crazy with feedback you must set a minimum success criteria.
What kinds of responses are considered a success and how many of them will you need in order to decide if you have conclusive results. You should also determine how many negative responses are considered an undeniable failure. If you’re working on a team, decide this with the core players ahead of running your experiment.
For Instagram, a MSC might have been “5 out of 20 people agree they want a cool way to take pictures on the iPhone.”
3 Phases of Experimentation
To conduct experiments that move your idea on a positive trajectory, there are three different phases of experimentation, each requiring slightly more investment of you and your potential customer.
These phases of experimentation are what keeps your overall costs down, and your feedback relevant.
In the early stages of app idea development, I would recommend going through these phases twice ensure you collect as much information as you can before you move on to the next stage. I’ll detail each round at the bottom of each subhead.
Phase 1: Exploration – Reproduce Problem Customer is Having
Conduct customer interviews with real potential customers (not family members!)
You are looking to have your customer/problem hypothesis validated by presenting your assumptions and riskiest assumptions during customer interviews.
Interviews like this can be relatively easy to collect and low investment for you to book. Phone calls to local businesses, attending relevant meetups and asking for feedback, and reaching out to industry professionals over Linkedin are just some of the ways you can collect feedback during this phase of Experimentation.
See how Trevor Owens used Craigslist to validate an idea:
Conduct surveys through any of the methods mentioned above by asking questions gathering feedback. Once your assumption has been validated, move on to Phase 2 – Round 1.
After you’ve validated your assumptions from Round 1, create a highly functional prototype using Balsamiq or Keynotopia to clearly demonstrate the UI for your app and collect feedback on basic functionality.
Phase 2: Pitch – Collecting Currency
This is where you ask your customer to actually give you something in exchange for solving the problem.
This could be an email address, cash, or some other currency where your customer is proving they’re invested in your idea.
Round 1: Of the people who agree your app solves their problem from Phase 1 – Round 2, collect their email address in exchange for updates on the projects growth.
If you decide to crowdfund later, these are the first people you will ask for funding. If you go the VC route, this list will be valuable in presenting that people have expressed interest in your functional prototype.
Round 2: After your hypothesis has been validated through Phase 1 and Phase 2, and you’ve amassed a decent list of email addresses (between 100-500 ideally), it’s time to pitch your functional prototype in exchange for real money. You could do this by crowdfunding, approaching Venture Capitalists, or doing the “friends and family” route of funding.
Whichever way you decide to seek funding, having an email list of clearly defined customers interested in having their problems solved is one of the greatest assets you can have when launching your idea and creating a Minimum Viable Product.
Pressgram, and Instagram alternative has a wonderful pitch video that demonstrates having a clearly defined customer, problem, and validated risk assumptions.
Phase 3: Concierge – Deliver Customer Expectation
This is about delivering the customer expectation with as little technology as possible, to as few people as possible.
Using Pressgram from above as the example, this would mean delivering an app that takes photos, adds filters, and allows you to share to social networks.
This might not mean having a fully featured social network like Instagram, but then again, that’s where you get into the philosophy behind the app, so maybe not having a social network isn’t such a bad thing.
For Pressgram, John pitched for $50,000 to be created. In the end there were 498 customers.
This may seem like a lot, especially when you consider the “to as few people as possible” sentence from earlier. But put it in perspective of Instagram now having 90 million monthly users, just under 500 seems like just the right amount to get the thing off the ground.
If you rewind back to October 6, 2010 when Instagram was started, their third blog post states that their Minimum Viable Product (an HTML 5 web app btw) only had “80 users at the time”. Those 80 helped them reach 1 million in just under 2 months.
All because they incorporated the feedback into building a minimum viable product to a select group of people.
Round 1: Deliver a functioning Minimum Viable Product to the first group of people. For Instagram this was creating an HTML 5 web app to their first 80 beta testers before building the native app for iOS and launching in the App Store.
Round 2: Get out of Beta and Launch to more people. At this point, the idea is to do a real launch and learn from your customer feedback all along. Even after you’ve delivered the first iteration of your product, you’ll be listening to customer feedback and incorporating/removing features along the way. After launch, the Concierge phase is delivered by way of updates through the app store.
Validation or Invalidation?
At every phase, test to see if your riskiest assumptions are valid or not. Your riskiest assumption again is determined by whether or not the business would fold if the riskiest assumption is proven wrong.
Even after the app has been launched, you’ll be testing these assumptions with a percentage of your users vs. massive sweeping rollouts to ensure that the majority of your users will be satisfied (even if you do suffer some losses).
Even though there was a big public stink about it, it was confirmed that Instagram saw 10% growth in active users since the privacy issues were raised in the tech press.
How did they know it would be ok? By testing the assumption with a pre-determined group of users.
If your Riskiest Assumption was validated, brainstorm and test the next Riskiest Assumption that will help you improve and grow your app.
Note: If you validate with the wrong customers, you’re hypothesis was not validated.
Do not pass Go. Move back to “Exploration” with new customers.
If your Riskiest Assumption is invalidated, pivot your Customer or Problem hypothesis based on what you’ve learned from the experiment.
A pivot is exactly what it sounds like. It’s about taking the core idea and applying it to a new group of customers, or modifying it slightly to fix a different problem.
This is exactly what Instagram did they removed most of the features from their location based, picture sharing network an app, and instead focused on allow users to apply cool filters to their photos and quickly share with friends.
“…we went out on a limb, and basically cut everything in the Burbn app except for its photo, comment, and like capabilities. What remained was Instagram” – Kevin Systrom
In the end, they pivoted the customer and the problem and modified the solution by keeping the core elements of Burbn.
Another great example – though not mobile specific – is Bufferapp’s pivoting the content strategy on their blog.
The pivot is all about learning from your customers and move in a direction they ultimately want.
We sincerely hope that The Validation Board for mobile process will give you a clear and actionable framework to take your idea from inception to launch. If you have any questions about the process, or would like some help getting set up, contact us and we’ll be happy to help you through your journey.
Check out these related posts:
“What would it feel like if our phones were designed around people, not apps?” – Mark Zuckerburg on Facebook Home You may have heard the news already, the “Facebook Home” is being released today. Technically, Facebook Home isn’t really an OS. It’s also not a “fork” of Google’s Android software. It’s an App layer […]read more >
You can’t stop thinking about how awesome your new app idea is, can you? If you could just get this thing out of your head and into people’s hands, you could change the world. But what’s the process to take a good idea for an app to a five star feature at the top of […]read more >
Tell me if this sounds familiar… You’re somewhere in the world doing something mundane – out to dinner, walking down the sidewalk, playing the drums on your steering wheel – when a sudden moment of inspiration washes over you, and you see the solution to a major problem with infinite clarity. Your first thought is, […]read more >