Failure as a product strategy

One of the companies I most admire is Zara. The Spanish retailer turned many industry assumptions upside down including:

- Foregoing the 4 season approach to product releases

- Creating a supply chain that can get a sketch into clothes in 100+ stores in 2-4 weeks

- Deciding that stock-outs were a good thing, leading to scarcity and desirability

If you want to learn about Zara, you can read the case study attached here.

One of the less discussed implications of the Zara model is how it changed the traditional concept of merchandizing.

In a typical soft line retailer, you have a bunch of people called merchandisers. Merchandisers are as close as you get to experts in subjects like “what today’s modern woman wants to wear,” or “what’s deck for the 20-25 year olds.” They try to figure out what the consumer wants to buy and then they make a number of decisions about what to put in the retail store. Collectively this is their “line” for a particular season, and this whole planning process might happen 6-12 months before the launch of that season.

Because of the speed and efficiency of its supply chain, Zara makes it cheap to fail. And because it’s cheap to fail, Zara can be much less deliberate with merchandizing. Consequently Zara ships roughly 12,000 different styles each year. Ideas for these styles come less from expert merchandisers and more from suggestions from the stores themselves. It’s OK to throw a bunch of spaghetti on the wall to see what sticks so long as spaghetti is cheap and abundant.

Looking at Zara's financial performance, this seems to work. A dozen cheap experiments, half of which fail, seem to work better than the few careful bets of the expert tastemakers. This is a pretty profound shift in mindset, from “how to we increase our probability of success?” to “how do we decrease our cost of failure?”

I think the software industry is experiencing a similar change in mentality as more and more software development moves to a “brute force” method of product design. This is something that software as a service, open source and agile development have in common: they’re very cheap to fail.

- SaaS products can introduce a new feature and if it fails, can withdraw the feature fairly quickly without much cost for rolling the feature back.

- Open source products get new features all the time from engineers that work for free. Bad feature? Throw it out and it didn’t cost you anything.

- Software products built using agile can course correct mid-project without throwing an entire release out the window.

I think we’re going to find the brute force approach to software product development appearing in more and more places over time. Cheap to fail may become an industry’s new competitive weapon.

[Strategy], [Product Management], [SaaS], [Open Source], [Agile]