“Startup success can be engineered by following the right process, which means it can be learned, which means it can be taught.”
The Lean Startup was published in 2011, yet its impact has been enormous. Companies are still getting to grips with the ideas set out in the book, most of which were not new in the first place. The value of those ideas and methods are perhaps even more valuable to large established organizations than to the startups which bear the books name. Author Eric Ries even defines a startup broadly as any “human institution designed to create a new product or service under conditions of extreme uncertainty.” Let’s take a look at how the methodology helps us to innovate and create value for the customer.
1. Build-Measure-Learn
If there is one idea which has transformed the way we pursue innovation today more than any other, it’s the idea of using the scientific method to handle uncertainty. This means defining a hypothesis, building a small product or feature which can test that hypothesis, then learn what happens, and adjust accordingly. This simple method is showing tremendous results, and enables companies to make small bets on many ideas at once, and allow the findings to determine which ideas move through the gates.
Build-Measure-Learn can be applied to almost anything, not just new products. You can test a customer service idea, a management review process, website text and offers, or a new feature to an existing product. It’s important that you can clearly test and validate the hypothesis though — you must be able to gather enough data or metrics to measure the results of the build.
The goal is to find the quickest way to iterate through the Build-Measure-Learn cycle. You’ll want to find out whether it’s worth another cycle, or to stop and move on to another idea. This means defining a very specific idea to test, and minimum items to measure. With products, you’re looking to test whether customers actually want or need it.
“We must learn what customers really want, not what they say they want or what we think they should want.”
Source: The Lean Startup
2. The Minimal Viable Product (MVP)
Traditional product development involved a lot of upfront work to define the specification of the product, and significant time and money invested in building it out. The lean startup encourages building only the amount of product that is needed to iterate through a single cycle of the Build-Measure-Learn loop. This is the minimal viable product.
“The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.”
You don’t necessarily need to write a line of code to create an MVP — it could simply be a slide deck describing the customer journey, or a set of design mockups. As long as you can test your hypothesis with real customers, and get enough validation to move through another cycle of learning.
3. Validated Learning
A fundamental requirement for the lean startup is to ensure you are testing a hypothesis with the right learning in mind. It’s very easy to focus on so called vanity metrics, which might give you the feeling of making progress, but actually don’t tell you anything about the value of the product.
The number of likes on Facebook might be a vanity metric; perhaps even for Facebook the number of accounts created is a vanity metric, the real value lies in the average amount of time spent on Facebook per day, per user — this tells you something about the true value and stickiness of the platform.
“By all accounts, what impressed investors the most were two facts about Facebook’s early growth … More than half of the users came back to the site every single day. This is an example of how a company can validate its value hypothesis — that customers find the product valuable.”
Lean Startup author Eric Ries provides an example from his own experience. IMVU was showing the chart below to their management and investors, painting a good picture — registrations were going up like a hockey stick graph. However, it was not showing whether users actually valued the service, and it was hiding the marketing costs to acquire new registrations. This was a chart showing vanity metrics, and not testing a hypothesis designed to give validated learning.
Source: The Lean Startup
4. Innovation Accounting
“Innovation accounting enables startups to prove objectively that they are learning how to grow a sustainable business.”
The process is done with three steps, as follows:
- Establish the baseline. You can run an MVP test to set some benchmark data points. This might involve a smoke test, with pure marketing, just to see if there interest from potential customers. It might involve a sign-up form online to see if customers would buy a product or service. From here you can set the baseline for the first cycle of the Build-Measure-Learn; even if the numbers are bad, it is a starting point from which to improve.
- Tuning the Engine. With the baseline established, the next step is to make a single change which can be tested to improve upon it. Rather than making many changes at once, focus on one single thing. This might be the design of the signup form; does it increase the number of conversions? Tuning the engine should be done carefully, by testing one hypothesis at a time.
- Pivot or Persevere. After making several iterations through the cycle, you should be moving up from the baseline towards the ideal goal set out in the business plan. If this is not happening, it should be obvious because of the incremental learning steps taken along the way.
5. The Pivot
“What differentiates the success stories from the failures is that the successful entrepreneurs had the foresight, the ability, and the tools to discover which parts of their plans were working brilliantly and which were misguided, and adapt their strategies accordingly.”
Making the decision to pivot is one of the hardest aspects of the Lean Startup method, because founders and entrepreneurs are emotionally tied to their products, energy and money have been ploughed into them. Problems such as vanity metrics and not testing the right hypothesis can lead teams down the wrong path; if the hypothesis isn’t clear, then failure can seem elusive, because you don’t know with certainty that this endeavor isn’t working. “Launch it and see what happens” always results in a positive outcome: you will indeed see what happens!
A pivot is not necessarily a failure, it means that you will change one of the fundamental hypothesis that you started out with. There are different variations on the pivot:
- Zoom-in pivot. A single feature in the product now becomes the entire product.
- Zoom-out pivot. The opposite of above. A whole product becomes a single feature in something much larger.
- Customer segment pivot. The product was right, but the original customer segment wasn’t; changing to a different customer is necessary, but the product remains the same.
- Customer need pivot. Through validated learning it becomes clear that a more important problem needs to be solved for the customer than the original.
- Platform pivot. Often platforms start out as an application, but due to success it grows to become a platform ecosystem.
- Business architecture pivot. Geoffrey Moore’s idea of switching from high margin, low volume, to low margin, high volume.
- Value capture pivot. Changing how value is captured fundamentally changes everything else in the business (marketing strategy, cost structure, product, etc).
- Engine of growth pivot. Startups typically follow one of viral, sticky, or paid growth models, according to Ries. Changing from one to the other might be necessary to fuel faster growth.
- Channel pivot. The internet has created many more channel options for startups, and complex sales or advertising channels are far less dominant. A startup has many more options from the get-go.
- Technology pivot. A new technology can offer substantial benefits in cost, efficiency, or performance, and allow you to keep everything else the same (value creation, customer segment, channel, etc).
“Pivots are a permanent fact of life for any growing business. Even after a company achieves initial success, it must continue to pivot.”
6. Small Batches
The story goes that a guy has to stuff newsletters into envelopes with the help of his two daughters. The children suggest they first fold all the newsletters, then put stamps on every letter, then write the address — do every task one by one. The dad wanted to do it differently, completing every envelope fully before moving onto the next. They competed to see which method was faster.
The dad’s method won, because of the approach known as “single-piece flow”, often used in lean manufacturing. It seems more efficient to repeat the same task over and over, because we assume we’ll get better and faster at it as we go. But individual performance is not as important as the overall performance of the system. Time is lost between the ‘batches’, when you have to restack the letters, and prepare the envelopes. When you consider the whole process as one single batch, you improve efficiency. Check out this video evidence: https://www.youtube.com/watch?v=Dr67i5SdXiM
Another benefit to small batches, is that you can spot an error immediately. If you started the other way, and found that after folding all of the letters, they didn’t actually fit properly into the envelopes, you’d have to start all over again. The small batch approach would find this error right from the start.
“The biggest advantage of working in small batches is that quality problems can be identified much sooner. This is the origin of Toyota’s famous andon cord, which allows any worker to ask for help as soon as they notice any problem, such as a defect in a physical part, stopping the entire production line if it cannot be corrected immediately.”
7. The Andon Cord
As just mentioned, the Andon Cord was used by Toyota to allow any employee along the production line to call a halt to the system if a defect was discovered. The longer a defect continues along the production, the harder and more costly it is to remove. Spotting a problem immediately is highly efficient, even if it means stopping the whole production line until it’s addressed. The method is the root cause of Toyota’s historically high levels of quality.
“The key to the andon cord is that it brings work to a stop as soon as an uncorrectable quality problem surfaces — which forces it to be investigated. This is one of the most important discoveries of the lean manufacturing movement: you cannot trade quality for time.”
Eric Ries explains that at IMVU they implemented a detailed set of automatic checks which ran every day, they would ensure the basic workings of the site (such as a ‘purchase’ button) still operated. This meant that any production errors were caught quickly, and automatically; and no more changes were put into production until it was addressed. It was the programming equivalent of the andon cord.
8. Continuous Deployment
For some it may seem a little dated in 2016, given the standardization of SaaS applications, but for many, continuous deployment is a scary and unimaginable scenario. The idea is that you are constantly updating your live production systems, all day, every day.
As early as 2009, IMVU were running up to fifty updates a day to production code. This was possible because a significant investment into test scripts — around 15,000 test scripts would run over 70 times a day, simulating everything from user clicks on the browser, to running back-end code in the database. To get a feeling for how this was done, read Timothy Fitz’s (IMVU developer) blog post about it.
Wealthfront is another case study in the book (an online investment management tracker). The company operates in an SEC-regulated environment, yet practices true continuous deployment, with more than a dozen production releases every day. You can read more about their setup on the Wealthfront Engineering Blog.
“The essential lesson is not that everyone should be shipping fifty times per day but that by reducing batch size, we can get through the Build-Measure-Learn feedback loop more quickly than our competitors can. The ability to learn faster from customers is the essential competitive advantage that startups must possess.”
9. Kanban
Kanban is another technique borrowed from the lean manufacturing world. Ries provides an example from Grockit (an online skills improvement tool for standardized tests). Grockit creates ‘stories’ in their product development process; stories are developed to build a feature, they include what the benefit and outcome is for the end user. These stories are then validated to see if they work — a split test is used to confirm the improvement to the customer experience. Kanban has four states:
- Backlog — items which are ready to be worked on, but have not yet started
- In Progress — items currently under development
- Built — development has finished work on the item, it’s ready for the customer
- Validated — item has been released, and it’s been positively validated
If the story failed the validation test, it would be removed from the product. Good practice is to set that none of the four stages (buckets) can contain more than three projects at any one time. If a project has been built, it cannot move into the validated stage until there is room for it (less than three already in there). Similarly work cannot begin on backlog items until the in progress bucket frees up.
Source: The Lean Startup
A highly valuable outcome of using this method is that teams begin to measure their productivity according to the validated learning from the customer, and not the amount of new features produced.
“I have implemented this system with several teams, and the initial result is always frustrating: each bucket fills up, starting with the ‘validated’ bucket … Pretty soon everyone gets the hang of it … As engineers look for ways to increase their productivity, they start to realize that if they include the validation exercise from the beginning, the whole team can be more productive.”
10. The Five Whys
Most technical problems have at their root a human cause. Using the five whys technique allows you to get closer to that root cause. It’s deceptively simple, but hugely powerful, and Eric Ries believes most problems which are discovered tend to stem from lack of appropriate training — but on the surface either look like a technical issue, or individual person’s mistake. As an example, Ries provides a case from IMVU where customers were complaining about a recent product update:
- A new release disabled a feature for customers. Why? Because a particular server failed.
- Why did the server fail? Because an obscure subsystem was used in the wrong way.
- Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
- Why didn’t he know? Because he was never trained.
- Why wasn’t he trained? Because his manager doesn’t believe in training new engineers because he and his team are “too busy.”
The technique is particularly useful for startups, as it allows them to find the optimal speed for making improvements. You could invest a huge amount in training, but it might not be the optimal thing to do at that stage of development — but by looking at root causes to problems, you can identify whether there are core areas that need attention, and not just always focus on the surface issues.
We also tend to overreact to things which happen in the moment, and the Five Whys helps us to take a deeper look at what is really happening. There can be a tendency to use the Five Whys as the Five Blames at first, with team members looking to say who was at fault for each step. The goal of the Five Whys is to find chronic problems caused by bad process, and not bad people. It’s also essential that everybody is in the room together when the analysis is done; all of the people impacted by the issue (including management and customer service reps). When blame has to be taken, it’s important management (or the CEO) takes the hit for not having a system-level solution in place to prevent the issue.
Good practices for getting started with the Five Whys:
- Mutual trust and empowerment. Be tolerant of all mistakes the first time; never allow the same mistake to be made twice.
- Focus on the system-level. Most mistakes are because of a flawed-system, keep people focused on solving problems at that level.
- Face unpleasant truths. The method is going to surface unpleasant facts about the company, and the effort to fix those early difficult issues is going to be substantial. It can easily turn into the Five Blames. This is where senior management buy-in is critical, to act as referee, ensuring that the process is followed.
- Start small, be specific. You want to get the process embedded, so start with small issues, with small solutions. Focus on running the process regularly, involving as many people as you can.
- Appoint a Five Whys master. This person is the primary change agent, so they need to have a good degree of authority to get things done. They are accountable for the follow-up and judging whether the investments in preventing problems are paying off or not.
Using the Five Whys alone is a great way to move towards a more adaptive organization. But it’s deceptively hard — those with young children know how challenging it can be!
“Some of the engineers I have trained to use it believe that you can derive all other Lean Startup techniques from the Five Whys. Coupled with working in small batches, it provides the foundation a company needs to respond quickly to problems as they appear, without over-investing or over-engineering.”
The Lean Startup is one of the best books on innovation and new growth creation in the past decade. It’s full of ideas like the above list, which can be implemented on their own, or in combination with the whole methodology. If you’re not using the Lean Startup ideas in your company already, you should be looking to do so soon.
Want to get more on the lean startup? Listen to the HYPE team discuss it on our book club podcast:
https://soundcloud.com/innovatorsbookclub/the-innovators-book-club-episode-1
Originally published at blog.hypeinnovation.com.
