In the mobile and app development world, we’ve moved away from the adage, “failure is not an option” to a new one: “fail fast.” Why many argue that taking this stance says it’s okay to fail and even encourages it, I would argue otherwise.
But before we dive into the reasons failing fast works (at least in my humble opinion), let’s look at what that really means. In my mind, failing fast means releasing an app or build before you consider it completely perfect. Because, let’s be honest: it never will be 100% perfect. Release what you’ve got and then get feedback from users for improvement. Tweak, submit new version. Lather, rinse, repeat.
App development is rarely ever complete. Instead, it’s a constant process of improvement. Even when your app is close to perfection, there are always more features you can add or ways to enhance it.
You Don’t Have Enough Info Not to Fail Fast
When we first build an app, we don’t yet know what can go wrong or what we need to work on. On his blog, Roger Valade said it succinctly:
One of the characteristics of failing fast that I find compelling is that it provides direction in the face of ambiguity or uncertainty, particularly in those early stages of a project or effort during which we lack the information or context to make effective decisions…
The longer you wait to release an app, the more problems can arise, and the more work you’ll make for yourself.
Don’t Sit Around Waiting for Your Competitors to Pass You
Another reason to not wait for perfection is: someone else will beat you there. If you’re working on a game-changing app in the productivity category, you’ve got no guarantee that someone else isn’t working on a similar app. And what happens when they release theirs first? It makes those best apps lists you covet, and gets more viral spread because it was first. With more than 1.1 million active apps on iTunes alone, you simply can’t afford to believe you’ve got a totally innovative idea.
Sometimes a Soft Launch is Better
The more users you have, the bigger the backsplash if it goes awry. As David Iwanow, SEO Product Manager at eCG says, “if it's a bad product, you don't want [it] upsetting too many users when [your company] folds because [your] product is poor.”
In other words, it’s better to upset a handful of customers with a poorly-designed app than thousands of users.
Go with Minimum Features
Your customers don’t need all the bells and whistles at first. Sean Byrnes, Founder of Flurry, says starting small lets you analyze what your users really want and build from there:
You need to focus on the minimum feature set that will allow you to see if your product resonates with customers and do that very well. If you find that customers respond well you can start adding features and getting more complex.
All this advice isn’t to say that you should release an app riddled with bugs. Get it functioning and get it out, then ask your users for their feedback. What could be improved? What kinks need to be worked out? Be proactive in checking user reviews on your app marketplaces and responding when there’s a complaint.
Failing fast doesn’t have to invite failure. Instead, it helps you prioritize those features and bugs that your users want you to work on, as well as see your app in action. Sometimes all the in-house testing you do is no substitute for actually getting it out in the marketplace and in the hands of your users.