After a long summer of awesome fiction reading, I am finally returning with a business book post! Today’s book is The Lean Startup by Eric Ries. In it, Ries explains the Lean principles he and his teams have developed over a long career of leading, working in and advising both startups and innovation engines within large, established companies.
Overall, I found this book really interesting, and there are a number of practical techniques I think I could immediately apply in my own work life (more on this later!). There were some principles that I found difficult to believe (such as that large batch working is less efficient than small batch working in the long term) but Ries makes a convincing argument, backed up by plenty of case studies and research. I want to give you a flavour of the book’s takeaways in this post, and also dwell on a few of the concepts I found particularly interesting.
Five Underlying Principles
Ries talks about a number of different useful techniques, but all are underpinned by these five principles:
Entrepreneurs are everywhere: you don’t need to work in a start-up to be an entrepreneur. He uses a term I rather like – ‘intrapreneur’ – to describe those who innovate within established companies.
Entrepreneurship is management: science and creativity go hand in hand and, once you have that first great idea, you need to apply logic and measurement to what happens next. Startups can and MUST be managed. In Ries’s words, “Science is one of humanity’s most creative pursuits” (p283).
Validated learning: experimentation is absolutely essential to long term success, and customers should continually experiment with how to make their products better and rigorously test the success of those experiments.
Build-Measure-Learn: companies should focus on making this feedback cycle take as little time as possible. In one of the examples he gives, from his time at IMVU, he discusses worrying about shipping a product to market that barely worked, only to find customers didn’t even download the product. Let alone worrying about if the features in the product were good enough, the team had a bigger problem on their hands – nobody even got as far as using the product! Better to discover this earlier than later.
Innovation Accounting: it’s important to look at the right metrics when you evaluate startup success. Don’t use vanity metrics that mask the real situation. For example, you ship a new feature and your gross user number goes up, so you assume it’s because of that feature. What you need to do is A/B testing within cohorts, so that the new feature is the only difference between group A and group B within one cohort. Then measure their behaviour to see if the feature has really made a difference.
“In other words, the Lean Startup is a new way of looking at the development of innovative new products that emphasizes fast iteration and customer insight, a huge vision, and great ambition, all at the same time” The Lean Startup, p.20
Consolation Learning versus Validated Learning
It’s popular now to talk about “learning culture” at work. In fact, I think in every company I’ve worked in the culture has supported the view that as long as we learn something no effort was wasted. Reis makes a very good point in his book; that there is a big difference between learning as consolation, and validated learning.
“Validated learning is backed up by empirical data collected from real customers” The Lean Startup, p.49
I have seen ‘consolation learning’ before all too many times – teams making sustained mistakes and failing to deliver on an output, but making themselves feel better because they learned something from it. I have almost certainly done this myself too. If the cause of the failure is not well understood then what is to stop it happening again and again… Ries’s point is that you should put in the minimum effort to experiment, do targeted testing to reach your specific learning, and then pivot accordingly. Mistakes should be arrived at in a controlled way, and never repeated.
Quality, Value, and Waste
I really liked some of Ries’s arguments around quality. He says that “Lean thinking defines value as providing benefit to the customer; anything else is waste” (p.48). The premise is that, if you do something incredibly efficiently, but it’s the wrong something, you have essentially wasted your time. Before entrepreneurs or developers (or any of us) rushes into trying to build a solution to something, it’s best to ask if customers actually have the problem we’re trying to solve. Moreover, if they did, would they buy a solution? Would they buy it from you? These for Ries are the fundamental questions which need to be tested as early as possible in order to build a sustainable business.
It’s for this reason that he advocates the creation of MVPs (minimum viable products) in order to test customer reception with the least possible investment. When teams are reluctant to compromise the quality of their output, he replies “if we do not know who the customer is, we do not know what quality is” (p.107). This is actually a brilliant argument, which he illustrates with a funny story from his time at IMVU. They built avatars for instant messaging, and were getting feedback that customers wanted to be able to move their avatars around the virtual world. The team wanted to make the avatars move like they would in a sophisticated game like the Sims, however they didn’t have enough budget, so the seemingly pathetic fix they shipped was to have avatars teleport from one place to another. Far from being disappointed, customers were delighted with the rapidity of the feature and even commented that it was “more advanced” than the Sims. In this case, an MVP allowed the team to discover what the customer really cared about – and what “quality” looked like to them.
For Ries, anything that doesn’t add value for the customer is a waste, and you should waste as little time as possible in testing to discover exactly what DOES add that value.
“As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek” The Lean Startup, p.110
Data and its uncertain meaning
When I first started working heavily with data, I found it a little overwhelming. If you’d told me when I started my career that I’d end up performing roles where my chief responsibility was to pore over and understand data, I wouldn’t have believed it. Over time though, I have developed a real love for raw data over cultivated dashboards. Although they say numbers don’t lie, they can absolutely be misleading and open to interpretation, and can be spun to present many different perspectives. I think it’s really important to understand the many, many dimensions of data behind a business, understand what metrics matter to you and evaluate them really honestly.
Ries calls this out where he talks about “vanity versus actionable metrics”. For example – a company may have an ever increasing number of new users hitting their landing page, but what if the number converting into paying customers is low and static? His rules for dealing with data are simple and rather useful I think:
Actionable: Data must demonstrate clear cause and effect, otherwise it’s a vanity metric.
Accessible: You should make reports as simple as possible so everyone can understand them. When data is open to interpretation or confusion it’s not empowering or useful.
Auditable: the data must be as accurate as possible and the way it’s generated must be clear. Otherwise managers can argue against the veracity of the data when challenged.
The Five Whys – a method for bug fixing
I’ll leave you with the “Five Whys” method, which Ries has used to uncover route cause of issues, and prioritise energy for making fixes. It’s a neat, practical method that you could start applying in your work. When faced with an issue, you ask “why” in succession, until you’ve reached the deeper cause of the issue. For example, what seems initially like a technical issue might actually be an issue with poor training. In order to prevent this method collapsing into what Ries calls the “Five Blames” (!), it’s important to realise that processes and systems, not people are usually at fault.
“The goal of the five whys is to help us see the objective proof that chronic problems are caused by bad process, not bad people, and remedy them accordingly” The Lean Startup, p.234
As you progress in answering each of your “whys”, small fixes can be introduced, with effort proportional to the problem. I liked this method because it’s incredibly easy to just address symptoms of a problem, rather than actually dig deeper and eliminate the cause of the problem entirely. It always seems like it’s too time consuming but, of course, ultimately in the long run this is likely counter-intuitive.
Thus concludes my review, but I’m hoping to bring non-fiction reading reviews to you more frequently in the coming months. If you have any book suggestions for me, I’m always keen to hear them!
Comments