Over five years ago, Jeff Atwood wrote Fail Early, Fail Often. Since that time I’ve seen two wildly different interpretations manifest themselves. From application developers and from VCs pushing products two strategies have seemingly been developed.
Two Strategies: One is right.
The first is the tried and true method of failing early. To take an idea, quickly build a product that conveys the idea and samples the market. The best example of this is the first generation iPod. There were plenty of music players, but having a hard disk was still largely untested. Apple stuck with what they already knew (Firewire, etc) where they could. The first product was very, very simple. It only served to test the idea. The product worked, though. That’s what matters. It may only cover 25% of the possible features, but with 100% completion.
The second strategy is a very different approach. It seems that in the last 5 years this is also the more common approach. It’s a “Quick to market” push that is misguided. Actually, it’s just bad. The strategy of covering as close to 100% of the possibilities but only with 25% completion is wrong. Navigating and using these products is like the Winchester Mystery House. There are stairwells right into walls. It’s maddening.
However, I understand. I know why it happens. Entrepreneurs are vigorous in their pursuit of a goal. It’s very difficult to look into the future. The idea seems so concrete at the start, but as the features near completion, new ideas and thoughts rise up. The pursuit of the new and noteworthy outweighs completion.
Define failure.
I believe that Jeff Atwood has it right when he says to focus on the failures. T biggest repeating failure in my own endeavors is my own ambition. I want, desperately so, to build grand products. I’m just one person. That can’t happen.
If I have people working for me then I can delegate completion. This only works if I can trust the developers to execute the vision I have. The last mile is the most important. Even great developers sometimes struggle to match up on a vision. Especially the young, ambitious developers that are attracted to developing new products. They want to solve problems.
Trying to cap the inevitable feature creep is a mighty challenge. By the time the real problem has been solved the enthusiasm wanes for the product. The real work then begins to build the product; a solved problem is not a product.
It’s far too easy to confuse a solved problem with a product. This is the source of many product failures. They deliver the solved problem but not a product. A product is the decoration, the experience. People, at worst, worked around the problem previously. Never forget that. Until a product is entrenched within the masses, it is always optional.
Measure failure.
A specific function of a marketing team is to be able to describe and measure the success and impact of a marketing campaign. At least the good teams, that is. They are able to determine if changes result in a positive outcome. They test ideas with statistics and information gathering. I wish application developers could do this, too.
I’ve heard and seen a confusion between success and failure countless times. Not just from young startups but from established companies old enough to know better.
Tablets vs. the iPad are a good example of this . Are tablets a good idea? The iPad would answer a resounding yes. However, the Blackberry Playbook and HP Touchpad have been abysmal failures. Even other Android tablets have failed to sell in any competitive quantity. Are tablets then a bad idea?
What exactly are people measuring? In order to measure the merits of an idea, the product must do the following:
- Clearly and distinctly solve the core problem.
- Offer a solution that is easier (or better) than the previous way of doing things.
- Not fail.
- Be better or cheaper than alternatives (See #2)
A failing product frustrates a user and removes them from wanting to use it. This in no way tests the idea. Likewise, a product that makes life more difficult with it than without, isn’t testing the idea. It’s testing the patience of the user, not the idea.
What actually failed?
So, assuming you can measure the success of the idea itself and not the perseverance of your users, you’re on the right track.
In the case of failure the most valuable lessons can be learned. Hopefully not much was invested and you failed early.
If there is certainty the idea is what failed, migrate the lessons. Evolve the idea or simply move on. Engage with the users.
Proving the wrong thing isn’t helpful.
But if the users aren’t talking about the idea but the product, the idea probably wasn’t tested that well. Unless they say the product is awesome, in which case congratulations.
But please, avoid the early release of a product with broken features. Remove the features entirely.
As I get more experience building products I’ve started to realize something. You don’t release with many features. In fact, the first release should strip away everything but the essential features. Then those features should be flawless.
If a product is released with a dozen features but they are built for seemingly the sole purpose of delivering misery, the product and the idea are unfairly persecuted. However, a product with one feature that operates well will develop a loyal and outspoken following.
The users will know their excitement will translate towards future greatness. Greatness happens through years of evolution, not months of furious and haphazard work.
Do your idea, your product and your users a favor. Strip out everything but the essentials. Use them day in and day out. Attack bugs and bad user experience with indefatigable commitment. Until then, don’t ship it. Please.
What has inspired me to write this is my frustration with the Amazon Kindle Fire. At the price point it has an amazing feature list. Unfortunately it’s maddening to use. I have yet to use it without getting frustrated.