Fail Fast, Learn Faster

Innovative teams of the most intelligent thinkers build products today at the speed of light. Some are winners and others are flops so what makes a team able to rebound from a failed release? If you ask many product managers today they’d tell you _fail fast_ but I'm not sold. 

Fail fast, early, and often
Teams embrace this concept and it’s been shown to work at times; yet, failing at any speed can only be half the plan if you want to stick around for more than a few failed releases. What makes continuous development, agile teams, and a fast paced environment productive is not failing fast, but rather learning from these trials even faster.

How rapid prototyping can lead to waste
With all the tools available today getting a working prototype out the door is something anyone can do and it can be done fast. Balsamiq is a classic for lo-res concepting, InVision is great for creating a clickable, interactive mock ups. There are plenty of others but before you chose any tool, or even decide to build something in code product owners should have clear goals and lessons they want to gain from the prototype in the first place. Leading with the goal to learn specific insights about your product, not to fail and try again later, will help define the focus of the prototype and inform the level of effort that should go into creating it. 

  • Define the core set of features for a release 
  • Identify areas that confuse or cause problems for users
  • Determine a clear user experience

These are all valid questions a prototype can help solve. Once you’ve established the goals you can select the format which will lead to the most valuable results. Then test! But instead of tossing out poor performing prototypes product owners must analyze these just a thoroughly as the winner. 
Learning why a prototype failed is equally valuable as understand what leads to success. 

  • What about the prototype displeased users?
    • Can you determine why? If not, retest. 
  • What was missing from the prototype? 
  • Why were uses looking for it? 
  • Why was it left out? Unsure, retest

Even these simple questions show that seeing failure in a prototype isn’t enough to make an informed decision. Get to the why and you’ll have a better idea of what should come next. Learn from your failures and you’ll start to fail less often.

Don't fail early and often. Prototype and learn, early and often.