Why You Need To Fail Quickly To Succeed

Developing an MVP, or Minimum Viable Product, is quite possible the most exciting and terrifying thing in the startup world.  You have this grand idea in your head that you are trying to get in front of the world.  A totally new concept that you are nurturing into existence.  It can be a new feature on your site, or a new product you are offering or even an entirely new company altogether.  

What makes this as equally terrifying as it is exciting is the thought that existed in the back of your mind on day 1 that is currently burrowing its way closer and closer to the top where it will all but consume you on launch day:  What if I fail?

Truth be told, you probably will fail in some fashion.  Nothing is a 100% success on the first try, but that doesn’t mean that it is bad.  In fact, there is a motto amongst the most successful tech & product leaders around.

Fail Quickly

This may seem like a self defeating statement, but it is actually an affirmation of positive progress.  When you fail quickly, that means you have discovered what is not working and can adjust to find the path to success as quick as possible.  This may mean scrapping your idea all together, or in most cases, it may mean that you have to tweak it here or there to get it just right.

How do we do this quickly?  No one wants to rush their idea into this world.  We want to incubate it until it is 110% ready for everyone!  But do you see the problem there?  You are building out what you think is perfect – not what your customers think is perfect.  

Don’t Be Selfish

Your startup will only ever be successful when you do it for your customers or clients.  If you are pushing your idea of a product down their throats and refusing to give them any input, you are doing it for yourself.  That, my friend, is selfish.  It is also the quickest way to burn through money, time and resources.

Take The Agile Approach

Agile development is quite the buzzword these days in the startup scene, and for good reason.  Being agile means exactly what you think it does.  It means that you put something out in front of the customer quickly, listen to their feedback and adjust.  By taking this approach, you can have your master idea put out in steps where each iteration is built on your original MVP plus a round of customer feedback, usage data, conversion data and any other relevant data that helps you track success.

You Still Need To Be Lean

Calling your development style “agile” doesn’t give you permission to put out whatever you want as your first round and then ask for feedback.  If you aren’t putting out a lean product, you are probably doing too much in each iteration.  Remember what we are working on here:  A Minimum Viable Product.  You should be doing the least amount of work possible on each iteration before you test.  If you are building an new feature for your site, say something as simple as a “favorite this article” button, your MVP should be only something as small as possible to get users involved.  I wouldn’t make it anymore than just a button that says “favorite this article.”  It would look nice and be placed in an appropriate spot, but that is t.  If no one clicks it, I failed on the first iteration and people probably don’t want it.  If people click it, great!  Now I get to expand the feature out for them by building a list of their favorites into their profile and I can keep iterating until I generate specific content for them based on what they like.  If I built that out entirely from day one, I would spend all of this time and money for something that people may not even want to use.

The Developer Dilemma

Now, product people, project people and execs love this.  Developers… not so much.  As a developer, I get it.  We are perfectionists and we don’t want to “cut corners” here and there just to get something out because we know what will happen in the future:  The boss will say “this is great!  Don’t go back to perfect the code, move forward with new iterations!”  This is an honest reality and as the boss, you will have to draw a line where you clean up the inevitable bugs that come out of all development and where you press on to build out the feature more.  Nothing that is full of bugs will resonate with your users, and on the other side of the coin, nothing that is perfected in development will ever get released.  If you plan this right from the start, you can have a clean codebase that has some basic test coverage and can be expanded easily on each iteration with minimal developer taxation!  This should help alleviate the pains that the dev team will feel when they have to release before it reaches their exacting levels of perfection.

The Slow Rollout

Here is where things get very interesting.  If you have a massive website already, you probably don’t want to release a minuscule MVP feature out to the masses.  NO PROBLEM!  Before you begin to write a single line of code, you can reach out to your users and ask them to become beta testers!  What a valuable user segment we just created together.

If you have a segment of users that are opted in to beta test new features for you, you can run some tech magic by flagging them in your database somewhere that makes sense as “beta users.”  When are writing your code, you can have a simple statement like this:

   if ($user[‘betaUser’] === true) {

       showNewFeature();

   }

   (example in PHP)

Now you have the ability to roll out features only to those that want these early gems and you can speak with them directly for feedback.  I have done this in the real world with outstanding results every single time and I always recommend this to startups that I advise.

Recap

All of my experience in the fast paced world of startup tech, even in enterprise level companies with hundreds of millions of users, failing quickly is the safest path to product success.  There are other ways to get there, but this removes the most risk from a time and dollar perspective.   I could write for days about the successes and failures that I have seen from agile / MVP / lean development, but I’d like to hear it from you.

What are your best successes, and more fun, what are your worst failures when building out a new product or feature and what did it cost you?