I read Eric Ries's Lean Startup from cover to cover for the first time this year. The book was first published almost ten years ago but it didn't take me so long to get to the book because I was unaware of the movement around it or because I disagreed with its basic premise. Having read individual chapters from Lean Startup and hearing a multitude of people discuss its lessons, I thought that sitting down and reading the whole book myself would have meant me studying concepts I already knew instead of uncovering new ideas.
But having finally read Lean Startup, I can gladly tell you that this was not the case. Some Lean Startup concepts and ideas were familiar to me, but I was surprised to read about some topics in the book. In this post, I'll share some of these unexpected lessons from Lean Startup.
All quotes are taken from Eric Ries and Lean Startup.
I was a devotee of the latest in software development methods (known collectively as agile development), which promised to help drive waste out of product development. However, despite that, I had committed the biggest waste of all: building a product that our customers refused to use.
Agile development teams pride themselves in collaborating with stakeholders and responding to new, unexpected business requirements instead of isolating themselves from rest of the business. However, these agile teams don't usually take any responsibility for the quality of the business requirements they receive. Agile principles assume that business is making smart decisions that are based on customer understanding and data. In reality, business might misinterpret data or try to convert their existing customer understanding from the offline world into the online world without enough new learnings.
In these situations, agile practices aren't going to save you from creating features that no one wants.
Imagine you're a product designer overseeing a new product and you need to produce thirty individual design drawings. It probably seems that the most efficient way to work is in seclusion, by yourself, producing the designs one by one. Then when you're done with all of them, you pass the drawings on to the engineering team and let them work. In other words, you work in large batches. From the point of view of individual efficiency, working in large batches makes sense. It also has other benefits: it promotes skill building, makes it easier to hold individual contributions accountable, and, most important, allows experts to work without interruption. Unfortunately, reality seldom works out that way.
Why is it that in practice cross-functional teams end up being more efficient than organizations of expert functions?
Unlike a joint effort of different expert functions, cross-functional teams are able to work in small batches. When you work in small batches, you are able to reduce delays, handover time, rework, and interruptions caused by problems overlooked by other functions.
The benefits of small batch work and cross-functional teams are counter-intuitive. Which is probably why businesses are still obsessed with specialization and experts over autonomous teams with more individual breadth than depth.
As the head of product development, I thought my job was to ensure the timely delivery of high-quality products and features. But if many of those features were a waste of time, what should I be doing instead?
The ability to plan and analyze is one of the key skills of business graduates. However, in the world of new product and service development, those skills have very little value. You can only plan and forecast when you have a long, stable operating history. Engineer students on the other hand might focus on building things reliably and efficiently instead of figuring out what is it that they should be building in the first place.
New product and service development is filled with stories of failure. From the perspective of your business and engineering studies, this failure might seem like professional failure: not being able to provide accurate forecasts or deliver value as promised can be seen as a sign of an unskilled analyst or manager. However, in Lean Startup, this failure is a necessary step towards learning more about your customers. Discovery work is much more closer to trial-and-error than professional craftsmanship.
Those who look to adopt the Lean Startup as a defined set of steps or tactics will not succeed.
Eric Ries does retell many validation stories from the likes of Dropbox and Zappos in his book. For example Dropbox's minimum viable product was simply a video in which they demonstrated how file sharing works using Dropbox. However, for every "proven" validation tactic you can find at least one counterexample. Readers of Lean Startup should take with them an understanding of the underlying principles of new product development—not a set of steps they can use to replicate success.