The Lean Startup (Review Part 2)

Author: Eric Reis
First Published: 2011
Amazon Referral Link: The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Review Part 1: The Lean Startup (Part 1)

This book is highly recommended for anyone that wants to explore more ways to grow and evaluate their own methodologies for development and successful processes. There are a lot of awesome ideas in this book that can strengthen methodologies and provide value to any organization. The following is an attempt to capture some thoughts on some of the big ticket topics of the book but this should not prevent you from reading it and seeing which ideas have the most relevance to you in your situation.

Validated Learning – Build-Measure-Learn

Having experienced the results of Validated Learning without having the words to describe it well, reading through this approach in the book provided a great sense of completion to many ideas and half-formed thoughts. The power of feedback is laid out in full glory here for all to see. Reading through the approach of first building something, finding a way to measure a response to that something, and then evaluating the measurements to see what can be learned from those measurements is an amazing premise that empowers a fast and agile product development that has many benefits. One of those benefits is a much faster ability to identify issues and potential pivots much faster and earlier than most methods. This can lead to huge efficiencies in terms of output effort as teams can learn from these feedback loops with real, actionable data and make changes as they go. It effectively builds a symbiosis between the users and creators of a product that allows both to grow the product together hopefully resulting in a much more amazing product than developers can create on their own.

One of the big ideas here, and upon reflection, one of the hardest things to implement, is the tightness of the feedback loop between the user and the developer on this Build-Measure-Learn path. This is identified in the book as one of the key elements to making this process successful. The idea describes that the shorter and tighter this loop, the faster the feedback and iteration of the actual product that is needed and wanted and therefore the quicker the product delivers value to the customer and the more efficient the development team is while building it. In short, it is a means to achieving greater efficiencies in the development cycle.

At least, it is in theory.

In practice and in reality, at least the one that I see on a daily basis this idea is not very easy to implement. These topics and ideas are great at targeting efficiency. They also are easiest to both visualize and implement on a medium that consists of a direct to consumers and delivered via web. For our purposes let’s say that SaaS (WPC Score: 7) is the ideal platform for building an application that utilizes the Validated Learning approach. A cloud application allows for direct interaction with users. From that platform experimentation can be performed on subsets of the user base and updates can be pushed anytime. Nice! Ok, let’s look at another product type.

How does Validated Learning work for a physical electronic product? The book makes a glancing pass at this topic by calling out a mechanical design project that they simply printed up 3d designs for a company and did many tight feedback loops for feedback and learning and achieved a lot of success for the product. That works great if the product being built is simply concerned with the external look and feel of the product. For a fully designed and implemented electronic product the process to follow here is a lot tougher. While many companies can afford 3d printers, very few companies have electronics fab shops close at hand. When tweaking and finalizing electrical schematics the need for actual physical boards and enclosures presents larger challenges that the Build-Measure-Learn path doesn’t necessarily account for.

Don’t get me wrong here – the Validated Learning method is based on a scientific approach to development. The method can be applicable to any development and management technique. This is no different than the argument that Agile can be used across an entire organization to manage everything. The reality of these is a little bit different. While it could be used as a universal approach, that doesn’t happen in practice. There are just other ways of doing things, there are too many ways that people are current inured to use in daily practice, and the methodology can be much harder to understand when the scenario isn’t as clear as a SaaS application. When it comes to products – having to pause for a 15-business-day turn on a PCB and then spending 2 more weeks writing firmware for it makes for a horribly long feedback cycle. Trying the iterate through a hardware design in this fashion would take a lot of money and time and would not be the most efficient method possible.

However, there is a tremendous amount of value in this approach. Even if you set all development aside and just use a concept like this for a planning phase without writing the first line of code or placing the first resistor, a tight feedback loop in conjunction with customer feedback can add a formidable amount of value to the planning stages of any product development. IMHO, when boiled down to a few key elements, this idea focuses on 3 key factors and if you can implement these you can add value to your existing workflows, planning, and products:

Focus on maximum efficiency – The goal is to work to not spend time planning, writing, and building things that aren’t needed. Build feedback loops to allow for earlier iteration and pivots in the product creation to attempt to maximize efficiency. The tighter your loops are between your developers and the paying customers, whether it be in planning or writing code, the better your products will be
Feedback loops are awesome – These can be applied between Engineers and users, managers and employees, when designing products, when building products, and in many other processes in the business world. The tighter you can make these loops the faster knowledge can be gained about the target and the sooner actions can be taken to effect continuous improvement
Don’t forget to learn – Small, tight feedback loops are great but don’t lose sight that actionable data must be measured here in order to have the information available to potentially make decisions and define what iterations need to be made. Having small cycles doesn’t provide any benefit if you aren’t learning from them. Implementing this methodology anywhere is critically dependent upon identifying the metrics and data needed to learn from the measuring step in the loop

The Five Why’s vs The Five Excuses

Thinking about this idea makes me want to summarize it in two words: frustratingly powerful.

The frustration with this methodology is not in the methodology itself, but rather in the implementation and execution of this technique. In theory it is very simple. Pick a problem. Ask why that problem exists. Provide a straightforward and simple answer to that. Then ask why that element or scenario existed. Continue this process until the question as to “why” the thing is that way has been asked 5 times. Then step back and evaluate the data collected and use that to make some decisions and identify some gaps or other actionable items to go work on improving. Simple, right?

The smart people behind this process and the author of the book seem to recognize the initial major frustration with this approach. In order for this to truly work the process cannot devolve into excuses at any point in the steps where the people involved are asking why and attempting to answer that question. Excuses can imply blame, they can be used to deflect from potentially painful reasons why something is wrong, and they are an avoidance of the real underlying root causes of an issue.

The second major frustration with this process is that it is really difficult in practice to provide a straightforward and simple answer to all of the “why” questions being asked. It is possible to do, but this can be a very hard and complex concept to master. Sure – someone teaching the process likes to present a simple scenario with an easy answer for illustration purposes. We all get that. How do you define an answer when the problem is complex and the answer is not obvious? What if there are multiple direct variables contributing to the current question being asked? How do you boil that down to the essence of the problem? It is very easy to follow the process for something simple:

Why did the customer not get the package on the target delivery date? We didn’t get the package to the shipping company before the 4pm cutoff for overnight shipments.
Why did we not get the package to the shipping company before 4pm? The package was ready but the signoff paperwork wasn’t signed so we couldn’t hand it over.
Why wasn’t the paperwork signed? The person responsible was in a meeting and wasn’t available for signoff.
Why couldn’t they have signed it earlier in the day? It was a rush job that came in at 3pm and they were already in the meeting
Why is there only one person allowed to sign the paperwork for a rush job? Because that is what the process says to do

That one was an easy one. Tweak the process and maybe add another person authorized to sign the paperwork, maybe add a step to interrupt a meeting in a scenario like this so that the customer needs can be met, maybe both of these or neither and the overall process is modified and away we go. No matter the outcome, asking why 5 times here got to the root of a problem. While it is an extreme example, how would a “5 Whys” analysis be performed on this question: “Why was the weatherperson’s forecast wrong at lunch today?” This one could be much harder to extrapolate. Was a weather model wrong? Did they even go outside to see what the weather was doing? Was there bad data from sensors in the system? For complex questions with multiple variables this process gets exponentially harder to complete successfully. How do you implement a solution throughout an organization where everyone can contribute to the process successfully?

The third major frustration with this method is the people involved. Even the example in the book talks about a leader in the company needing to come in and perform this analysis. There are two problems in regards to people. The first is that you need someone with enough experience, creativity, and insight to burn through the complex problems and isolate the variables in the problem so that simple answers can be given to the complex questions and the process can work as intended. The issue is that there usually aren’t that many of these types of people within an organization. We would all love to be surrounded by these types of people at work. The ones with initiative and foresight. The ones that can connect the dots and make things happen. However, they are hard to find and any company with an overabundance of these types probably wouldn’t need to do that many “5 Whys” analyses because those people would probably not waste time and would simply just fix the issues as they popped up. The second problem in terms of people goes hand in hand with the leadership problem. The people completing the exercise need to have the power to affect change based on the results of the exercise. Otherwise, why even do it in the first place?

Setting aside the issues with this methodology, the power of this process should be evident by now. If a strong and smart leader can tackle a major or minor issue using this methodology without blame or excuses the outcomes can be amazingly productive. This process can be a fantastic tool in your Continuous Improvement toolkit. Be wary of the pitfalls around very complex problems and weaker process leaders. With the right person at the helm then if the intent and execution of the investigation can stay focused on the “why” and not flip over to the “excuse” side of the fence then immense value can be achieved by simply answering the question “why” 5 times over.

As the post has grown rather long, the final topics for this book review have been bumped to a third post that will be posted soon. Please stay tuned…