"Success is not delivering a feature; success is learning how to solve a customer's problem."
- Scott Cook, founder of Intuit, quoted in The Lean Startup, page 66
"...the individual efficiency of these specialists is not the goal in a Lean Startup. Instead, we want to force teams to work cross-functionally to achieve validated learning."- The Lean Startup, page 271
One of the main foundations of the Lean Startup methodology is that of the “minimum viable product” (or MVP, for short). The goal of an MVP is to build just enough of something to quantifiably test a business assumption or hypothesis. It’s about shifting our brains from the assumptive to the curious. It’s about accepting a bunch of market data (if such a thing is available to you), but not relying on it as absolute fact. Let’s make this a little more concrete, so you understand what I’m talking about.
Feedback from a client group suggests that they have a problem. You believe that you can create a product or service to solve that problem. You believe that the client group would be willing to pay to solve their problem, using your solution. Maybe you even did a little bit of research that backs up your assumptions. Terrific. But, at this point, all your assumptions are simply that – assumptions.
Traditional business logic would say to spend 18 months in development, build a complete, and super shiny [product/service] then spend millions of dollars marketing that new thing to your target market. Go big or go home.
Lean Startup principles suggest you go the other way. Build the absolute smallest version of [product/service] you can and get in front of your target market group. Watch them use it. Listen to their feedback on it. Then improve. Ries calls this process BUILD-MEASURE-LEARN. It’s iterative, it’s eternal, and it radically improves your chances of success.
"Startups don't starve; they drown."- Shawn Carolan, Venture Capitalist, quoted in The Lean Startup, page 209
The challenge with building something new today is that we can do just about anything. “We have the technology! We can build him better, stronger, faster than he once was!” (to quote the Six Million Dollar Man.)
Super. But what if people don’t want “stronger”? What if they want a double dose of “faster” instead? As people involved in startup activities, we have a choice – we can build everything into our initial launch and then try to sort through that which worked from that which didn’t. Or, we can start lean, with one hypothesis – “Is our client willing to pay for a solution to this problem?” – test that hypothesis through a MVP, learn from the experience, and then build something simple to test our next hypothesis.
This quote from Ries sums it up pretty well: “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.”
And what’s the ultimate learning you’re seeking? Billionaire Entrepreneur, Scott Cook, made that abundantly clear in our opening quote: “success is learning how to solve a customer’s problem”. Nothing else matters… though there is a catch. (Which brings us to insight 2.)
"It is not the customer, but rather our hypothesis about the customer, that pulls work from product development and other functions. Any other work is waste."- The Lean Startup, page 201
Customer feedback is overrated. “Blasphemy!” you say. But I stand by my statement. Yes, absolutely, customer feedback is important. But the opinions of your customers (even your best customers!) should not the be-all-end-all of driving product development.
Think about the quote that opened this GEM, “It is not the customer, but rather our hypothesis about the customer…”. What does Ries mean by that?
Let’s say you get a piece of feedback from a customer; they share their opinion or suggestion on how you could make it better. Do you dive in and immediately create the exact solution they’ve outlined? Hopefully by now you know better. A much, much more effective solution is to build a minimum viable product (MVP) version of that solution. Think small – as small as possible. Then you test it with a small group of users. You watch for the ways in which the customers interact with the new feature. Is it improving their experience? Does it improve their experience enough that it will generate more business – either through increased sales or justifying a higher price point? Is there another way you could equally improve their experience, but faster and/or less expensively so that you could keep the price where it is?
The point here is that we always need to be developing in the best interest of the customer, but not necessarily at the customer’s direction.
I could quite literally write a book about this book. While I’m delighted to be able to share a few of the key points from The Lean Startup with you in this Actionable Summary, there simply isn’t the space to get into some of the gems like Lean Accounting Principles, Vanity vs Actionable Metrics, Pivots and a dozen more here, today. And so, I implore you – if you’re involved in innovation in any way, please – do yourself a favor and buy this book. Then read it. Then buy it for your team members. It may just save your business and/or career.
Eric Ries (born 1979) is a Silicon Valley entrepreneur and author recognized for pioneering the Lean Startup movement, a new-business strategy which directs startup companies to allocate their resources as efficiently as possible. He is also a well-known blogger within the technology entrepreneur community.
