Fail Fast

In a few short years I’ve been involved with a ton of development projects from iOS, Android and even BlackBerry to websites and web apps. All the projects I’ve been involved with, whether a personal idea or a product for a company have carried weight.

Out of all of those projects, only a handful could be considered successful and even fewer are still in use today. If there’s one thing all of these failed projects share is their complete unwillingness to just die. They just kept going and pushing on and failed anyway.

I’m sure an argument could be made about how they could have succeeded if they had done things differently. Whatever the reason, they sucked up resources for far too long. Most of these projects could have failed in a quarter of the time if anyone had bothered to make sure they failed fast.

Failing fast isn’t a bad thing, in fact quite the opposite. If a project is bound to fail, for whatever reason, get there as quickly as you can so you can learn from it and move on.

Iteration

The more advanced tech capitals of the world have learned this and now focus on iteration:

Prototype > Release > Assess > Repeat

By iterating, you avoid bloating your idea before you release it. Feedback on your prototype ensures you don’t build features that don’t appeal to the problems your audience has. Assessing success and failure after each release means that you can quickly see where your idea is headed.

Regardless of where it’s headed, get there fast. Don’t build something that people don’t really need. Focus on iteration and let the users guide you as much as possible.