The Lean Startup
By Eric Reis
Best Line #1: Always have a theory.
Best Line #2: Only 5% of entrepreneurship is the big idea, the business model, the whiteboard strategizing, and the splitting up of the spoils. The other 95% is the gritty work that is measured by innovation accounting: product prioritization decision, deciding which customer to target or listen to, and having the courage to subject a grand vision to constant testing and feedback.
I first read this book in 2013 and, since then, I’ve seen a rise in incrementalism, piloting, and “lean” process improvement. Whole positions and departments are dedicated to it now. It’s great. It’s also a wee bit ambiguous because I’ve yet to see two people speak of “Lean” in the same way. It’s a buzzword. Much like sustainability. Mix them together and you get something that is akin to the Balanced Scorecard and Six Sigma of the 1990s. Which is a shame because Lean is too valuable to be relegated to a fad.1 Let’s dive in and see what it’s all about.
What does it mean to be a LEAN startup?
Nevermind the startup lingo. It’s a distraction. Few have read this book because they don’t think it applies to them. But it does because everyone has a startup. Or rather, everyone has an aspect of their work that is new and is seeking deliver value amidst a high degree of uncertainty. So let’s instead consider what it means to be lean in New Orleans.
This is actually a good explanation. The highlight is the way in which they examined their work for the highest points of value and designed new processes to deliver that value more quickly.
Great. It also is highlighted in a previous account I wrote for the American Planning Association. Check it out if you need to get some sleep.
But this is about more than process. It’s about creating new, successful things—programs or products. That’s where the “startup” language really comes into effect. Process stuff, frankly, is boring. Again, read my previous article for further proof. For the good stuff, consider this first line from the author:
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.
It ain’t “fail fast”. To borrow from a previous post, you still have to return something that is net positive. The good news is that this is quite easy to do when you develop the right approach on the front-end.
How To Pilot A Pilot
In 2017, I read coverage about a policy experiment in Finland where 2,000 residents would be randomly selected and given a monthly stipend to simulate the implementation of a Universal Basic Income (UBI). This was at the peak of the UBI debate when people were shouting on both sides of the issue to say it was the best thing ever, the worst thing ever, and probably or probably not a good idea.
I was thrilled because the experiment would be a way to put an end to all the debate. No more yelling, no more economic extrapolations, no more speculative studies of what might or might not happen. I waited to hear the news.
It isn’t good. The worst of all possible situations has occurred: the experiment has been deemed a failure. This is not a reflection on UBI. I have no stake in that. Instead, it’s a reflection on the experiment itself which, according to the actual researchers from Finland, has been declared faulty.
There’s more to the story but, for now, let’s consider the importance relative to Lean management. We use the term “pilot” a lot in my line of work these days. There are many and they are not all created equally. Some pilots are new ventures, some are new changes to old ventures; some pilots carry a mandate for success and some are for mere exploration.
Any such pilots is perfectly valid. We only run into trouble when we fail to articulate the purpose upfront. For some, the term “pilot” means “don’t take this seriously.” For others, it’s a serious trial that spells the fate for a broader effort—as appears to be the case for UBI in Finland.
Here’s where our book establishes the first rule for developing a these efforts:
To do so, you need pre-made targets and clear, reasonable assumptions. A theory, in other words.
Yes, a theory. To some, this may sound corny. Like we should also don our white lab coats and pocket protectors. I’ve seen people roll their eyes at this idea. But why do a pilot if you can’t say what success will be? More importantly, setting the target is the only way to know if and how you miss. Of course, the trick is to then stick to those targets and not move them about.
This is the central complaint in our Finland story. The experiment’s parameters and expected outcomes changed midstream, rendering the whole thing flawed. Suddenly, any results and findings are in question and that’s the real loss—because you can’t really learn from that.
And learning is the key purpose of a pilot. As Reis puts it: Learning is the essential unit of progress for startups. The effort that is not absolutely necessary for learning what the customers want can be eliminated.
So a good pilot is bare bones, existing solely for learning what customers want (be they actual paying customers, residents in a city, students in a school, etc). It’s centered around four really great questions posed in the book that I think are a backbone for any endeavor:
(1) Do consumers recognize that they have the problem you are trying to solve?
(2) If there was a solution, would they buy it?
(3) Would they buy it from us?
(4) Can we build a solution for that problem?
In my field of government, I think these questions can be slightly rephrased to sharpen the focus:
- Do residents recognize they have the problem you are trying to solve? There isn’t always consensus around that.
- If there was a solution, would they accept the costs? Often, the solution is a trade-off; perhaps not a monetary cost but rather a slight diminishment in some intangible “quality of life” sense.
- Would they want us to provide the solution? A really important question; sometimes, our people don’t our interventions!
- Can we build a solution to the problem? Another hard question to answer.
If we really thought through those questions before every venture and tied measurable outcomes to each as a means of really gauging the truth, we’d probably do less stuff. But better stuff. From there, we can test the solution in the smallest, most useful way. But how?
Minimum Viable Product
Here is a good question that makes me feel lazy: what is the least amount that I can do and still get a good result? I’ve found that such a question usually gets me to a good place. In the framework of our book, this is how we land on the Minimum Viable Product or MVP. As Reis explains:
The goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses.
Emphasis on the last word: “hypotheses”. You can’t have an MVP and a viable test until you have a theory. For instance, I’ve come to believe that there are 10 basic rules that govern the built environment, 10 basic rules that can create the great urbanism we love in our well-designed cities. Practically everything else, the hundreds of other rules, are dependent upon that core. But how can I prove it? By using the MVP. I developed a course on how others can do this, too. Essentially, it required a model.
A lot of MVPs are models. Especially in the economic and policy world.
Or are they?!
The truth is, models aren’t MVPs at all. They’re concept tests. An MVP is the real thing you want to do—not a prototype or model—scaled down to the minimally viable size. So in my case of government development policy, the only true MVP would be the application of that given standard on, say, a city block. To learn from and then possibly expand. That’s the idea.
Coincidentally, that’s also why I highly doubt we’ll ever see MVPs for zoning or other regulation. It’s as hard to adopt an MVP as it is to adopt a full-blown zoning ordinance. This is where I get envious of tech companies. Good ones using this approach can learn so much more about what is and isn’t valuable. In my world, this is possible in process improvement but not so much in policy or service development. So it goes. That doesn’t mean we shouldn’t still try.
To get the closest to a true pilot on an MVP, we need to remember to define our assumptions (what will work, what won’t), design the service or product, find the smallest group to test it (usually the advocates or “early adopters”), and put our courage to the test. Why courage? Because the MVP will very likely be rejected.
That’s kinda the point.
As Reis puts it, MVPs often result in bad news.
But the bad news is good news! It lets you make mistakes at such a small scale, with such minimal effort, that you can find out what went wrong. So it’s just a really good first step. This is when the whole “fail fast” idea starts to make some sense. Yes, fail fast on the MVP in order to learn its weaknesses and pivot to the strengths.
How do you determine the weaknesses? This gets back to the ideal. When you start, you answer the four questions highlighted above and you crystallize your hypothesis into a set of measures. For example, the Universal Basic Income experiment (surely?) had some expected outcomes such as a measured increase in general well-being, health, and spending for recipients. So in running an MVP in a short cycle, you gauge the results, see how well it fits the benchmark measure, and begin the long game of optimization.
Assumptions start to be dispelled; new assumptions start to take their place. In every instance, the beauty of the MVP is that you have a chance to test the riskiest parts with little to no downside. It’s akin to doing a few years of “fantasy stockpicking” to test your methods before venturing into the actual Dow Jones. This gets to a good principle that I appreciate from the book:
When one is choosing amongst many assumptions in a business plan, it makes sense to test the riskiest assumptions first.
That feels obvious but what I like is the association of risk with an assumption. There absolutely is risk. Some assumptions, if wrong, carry a lot more downside than others. Thinking through that is helpful. I assume that a 10-rule zoning ordinance won’t cause a lot of public safety issues but I would need to test for that first before you move on to less-risky assumptions about, say, aesthetic cohesion.
Build, Measure, Learn … and Leave?
So here’s what Lean is all about: it starts with developing clear hypotheses, vetting our product or service ideas through a set of four core questions, establishing measurable expected outcomes we think we’ll deliver, and testing iterations through a series of MVPs to get to those outcomes until we do. It’s a lot of work. Unromantic work at that. Where’s the drama? The stroke of brilliance? The Eureka moment? Yeah, it’s nowhere to be found.
As Reis explains, Only 5% of entrepreneurship is the big idea, the business model, the whiteboard strategizing, and the splitting up of the spoils. The other 95% is the gritty work that is measured by innovation accounting: product prioritization decision, deciding which customer to target or listen to, and having the courage to subject a grand vision to constant testing and feedback.
It’s the idea of Build-Measure-Learn, a cycle that we try to implement on as fast a timeframe as we can so we can learn quick, adapt, and get closer to the true goal. So long as the intent is good and the MVP involves the right-sized groups (don’t go too big), this is something we can do for a long time to get to the right thing. However, there does have to be an exit point. There comes a time that several iterations lead to nothing more than spinning tires in the mud.
So what happens when we run these cycles, make these changes and pivots, adapt with every iteration, and still don’t get closer? Well, this is the hardest lesson of all: it either shows that the hypothesis is fundamentally wrong (e.g., UBI will not work) or the market for it is wrong (e.g., UBI won’t work for those people in Finland). For most things, I think the hypotheses are often okay but the market is likely bad. Here’s what Reis says:
In a great market–a market with lots of real potential customers–the market pulls product out of the startup. Which is to say that even a slightly-bad hypothesis can be successful so long as the market is strong. You might think people really like Taco Bell because it has great mexican food. The real truth is probably more about there being a strong market for cheap food. A strong market forgives a lot.
Conversely, in a terrible market, you can have the best product in the world and an absolutely killer team and it doesn’t matter–you’re going to fail. This is from Reis again and it points to that hard lesson some efforts deliver. Many are the times that good things come at bad times. To learn that lesson before a massive investment would be nice.
This book has a great deal more to it that everyone should read and absorb. In short, I think The Lean Startup provides us the playbook for dancing with uncertainty. New idea? New venture? Unproven demand? Fickle customer base? Demanding residents? Shifting political winds? So be it! All the more reason to apply the tactics we’ve covered this week to learn more about this uncertainty, gain some insights, make some improvements, and take more baby steps to victory.
Far too often, we are pulled into the vortex of Big Thoughts and Huge Problems and feel like we must scale our responses to the same size. Maybe. I mean, I suppose there are times when the military really does need to make another aircraft carrier. But if we borrow from our previous book, Essentialism, we can remember that every effort is an active search to find what’s most meaningful. Don’t bet big until you know what really matters. That’s probably the biggest underlying idea of the Lean method.
That and cycle times. Go through the Build-Measure-Learn cycle quickly. Don’t take so long to deliver progress. I fundamentally believe that if it takes two years, you’re building the wrong thing. Be it an Edsel or a strategic plan or, well, anything. Yes, the iPhone took five years to build. But they didn’t start by building an iPhone. They started with a better iPod, then an iPod with a phone, then an iPod phone with apps. You get the idea. If it takes two years, you’re building the wrong thing.
No one needs to be judged by their ability to just stay busy. We must instead be judged by our ability to find what matters, deliver it, and effectively avoid doing anything else. It’s hard but it’s worth it. This book can make it easier.
Buy it on Amazon.
Mental Models and Principles
- If it takes two years, you’re building the wrong thing.
- Learning is the essential unit of progress for startups (and any other new venture).
- Validated learning is backed up by empirical data collected from real customers.
- The right way to measure a startup is by how much validated learning we’re getting for our efforts.
- Think Big, Start Small.
- If you cannot fail, you cannot learn.
- Answer four questions before starting a new venture: (1) Do consumers recognize that they have the problem you are trying to solve? (2) If there was a solution, would they buy it? (3) Would they buy it from us? (4) Can we build a solution for that problem?
- Success is not delivering a feature; success is learning how to solve the client’s problem.
- Every business plan begins with a set of assumptions.
- Genchi gembutsu: japanese for “go and see for yourself”.
- No amount of design can anticipate the many complexities of bringing a product to life in the real world.
- When in doubt, simplify.
- A startup’s job is to (1) rigorously measure where it is right now, confronting the hard truths that assessment reveals, and then (2) devise experiments to learn how to move the real numbers closer to the ideal reflected in the business plan.
- A smoke test (like trying to get preorders) measures only one thing: whether customers are interested in trying a product.
- For a report to be considered actionable, it must demonstrate clear cause and effect.
- Whoever is left out of the discussion ends up being the target for blame.
- Organizations have a muscle memory.
- The minimum viable product
- Always have a theory.