The Lean Startup
Saturday, February 18th, 2017 | Books
The Lean Startup is a book by Eric Reis. In it, he discusses the concept of running a business using principles translated from lean manufacturing. He argues that the true purpose of a startup is to find a way to make a profitable business in the shortest amount of time and that any company of any size can implement these principles.
Reis argues that one of the most important things is to get a product in front of the customer. We often shy away from this because we do not want to tarnish our reputation or have people think we build rubbish products and put them off in the future. However, there is something far worse than having a bad product: building something that nobody wants.
Pouring time into a product customers do not want is a massive waste of time. Then, because you have invested that time, you will be reluctant to let it go, even though it is a dead-end from a business perspective. Instead, using a minimal viable product (MVP) to attract early adopters and then using those adopters to find out what you should build avoids all of this heartache. You can start with a concierge service. Solve a problem for just one customer and do it perfectly. The time for automated support systems is later.
Critically, you need to gather this data through revealed preferences. Asking people what they want is a bad idea: they do not know and cannot articulate it when they do. Instead, you need actionable metrics: what are people doing?
The way to get actionable metrics is to plan them in. Whenever you want to add a new feature, ask yourself how you will test whether it is an improvement. Propose an experiment, put a system of measurement in place, roll out the feature and see what happens. If to does not make things better, scrap the feature.
As the data comes in, you will have to decide whether to pivot or persevere. There are several different types if pivots:
- Zoom-in: focus on a specific area of the product
- Customer segment: focus on a different type of customer
- Customer need: keep the customer but change the problem you are solving
- Business model: B2B, B2C, margin levels, etc
- Value & growth: what is the monetisation method? What is the growth engine?
The key to much of this is to break things down into single piece flow. Much of our manufacturing is based on batch production. We reduced costs by standardising everything and making it in huge quantities. However, this has disadvantages: things cannot adapt or be individualised.
Batch is not the always the most efficient process, either. Take the example Ries gives: folding stuffing and writing the address for 100 letters. Should you batch each stage, or use single piece flow to fold, then stuff, then write out each letter before moving on to the next one?
Experimentation gives us the answer: single piece flow is faster. Batch seems the most efficient choice. However, this it is counterintuitive. Our mind does not factor in all of the time we spend moving piles around. Even in the best case scenario, batch processing is slower. And it can get much worse: if you fold the letters to find the envelopes are too small, you face disaster.
Lean startup methodology attempts to move the process back to single piece flow: each feature is isolated, testable and developed in its entirety before moving on to the next one. Reducing the amount of work-in-progress may feel less productive when you are stuck on a few slow-moving tickets, but is more efficient for the organisation overall (and the goal of producing a viable business).
Team efficiency is what is important here. For developers, it can often feel like you are constantly being interrupted by meetings. Which is true. However, your productivity is not what is important. The key metric is “is the team producing features that customers want”, not how much code you write.
When things do go wrong, the “five whys” method can help. It is simple: just ask why five times. For example:
- Why did the website go down? Because we introduced faulty code.
- Why did we introduce faulty code? Because the CI layer did not pick up on it.
- Why did the CI layer not pick up on it? Because the CI layer is not working, so we are manually running the tests.
- Why is the CI layer not working? Because Dev Ops have not been able to fix it.
- Why have Dev Ops not been able to fix it? Because they have not had the proper training.
This gets us to the root of the problem. It seems like a coding problem. To an extent, it is. However, bad code is always going to get written at some point because developers are human. The five whys method also exposes problems with the pipeline and lack of training within the organisation.
Summary
The Lean Startup is essential reading for anyone who wants to make their business more efficient. Successful businesses build things that customers want. The lean startup methodology attempts to uncover that and bring it to market as fast as possible. Everything else is a waste.
The Lean Startup is a book by Eric Reis. In it, he discusses the concept of running a business using principles translated from lean manufacturing. He argues that the true purpose of a startup is to find a way to make a profitable business in the shortest amount of time and that any company of any size can implement these principles.
Reis argues that one of the most important things is to get a product in front of the customer. We often shy away from this because we do not want to tarnish our reputation or have people think we build rubbish products and put them off in the future. However, there is something far worse than having a bad product: building something that nobody wants.
Pouring time into a product customers do not want is a massive waste of time. Then, because you have invested that time, you will be reluctant to let it go, even though it is a dead-end from a business perspective. Instead, using a minimal viable product (MVP) to attract early adopters and then using those adopters to find out what you should build avoids all of this heartache. You can start with a concierge service. Solve a problem for just one customer and do it perfectly. The time for automated support systems is later.
Critically, you need to gather this data through revealed preferences. Asking people what they want is a bad idea: they do not know and cannot articulate it when they do. Instead, you need actionable metrics: what are people doing?
The way to get actionable metrics is to plan them in. Whenever you want to add a new feature, ask yourself how you will test whether it is an improvement. Propose an experiment, put a system of measurement in place, roll out the feature and see what happens. If to does not make things better, scrap the feature.
As the data comes in, you will have to decide whether to pivot or persevere. There are several different types if pivots:
- Zoom-in: focus on a specific area of the product
- Customer segment: focus on a different type of customer
- Customer need: keep the customer but change the problem you are solving
- Business model: B2B, B2C, margin levels, etc
- Value & growth: what is the monetisation method? What is the growth engine?
The key to much of this is to break things down into single piece flow. Much of our manufacturing is based on batch production. We reduced costs by standardising everything and making it in huge quantities. However, this has disadvantages: things cannot adapt or be individualised.
Batch is not the always the most efficient process, either. Take the example Ries gives: folding stuffing and writing the address for 100 letters. Should you batch each stage, or use single piece flow to fold, then stuff, then write out each letter before moving on to the next one?
Experimentation gives us the answer: single piece flow is faster. Batch seems the most efficient choice. However, this it is counterintuitive. Our mind does not factor in all of the time we spend moving piles around. Even in the best case scenario, batch processing is slower. And it can get much worse: if you fold the letters to find the envelopes are too small, you face disaster.
Lean startup methodology attempts to move the process back to single piece flow: each feature is isolated, testable and developed in its entirety before moving on to the next one. Reducing the amount of work-in-progress may feel less productive when you are stuck on a few slow-moving tickets, but is more efficient for the organisation overall (and the goal of producing a viable business).
Team efficiency is what is important here. For developers, it can often feel like you are constantly being interrupted by meetings. Which is true. However, your productivity is not what is important. The key metric is “is the team producing features that customers want”, not how much code you write.
When things do go wrong, the “five whys” method can help. It is simple: just ask why five times. For example:
- Why did the website go down? Because we introduced faulty code.
- Why did we introduce faulty code? Because the CI layer did not pick up on it.
- Why did the CI layer not pick up on it? Because the CI layer is not working, so we are manually running the tests.
- Why is the CI layer not working? Because Dev Ops have not been able to fix it.
- Why have Dev Ops not been able to fix it? Because they have not had the proper training.
This gets us to the root of the problem. It seems like a coding problem. To an extent, it is. However, bad code is always going to get written at some point because developers are human. The five whys method also exposes problems with the pipeline and lack of training within the organisation.
Summary
The Lean Startup is essential reading for anyone who wants to make their business more efficient. Successful businesses build things that customers want. The lean startup methodology attempts to uncover that and bring it to market as fast as possible. Everything else is a waste.
