One of my goals for the next few weeks is to catch up on blogging about some great speakers I've seen recently. Coming soon, a post about seeing Dr. Atul Gawande (The Checklist Manifesto) and Daniel Pink (Drive) in the same week. I'm reading both books and, about 2/3 of the way through each, they are highly recommended.
Today's post will be about a talk given back in November, at MIT, given by Eric Ries, a blogger and speaker (and soon-to-be author) on the topic of “Lean Startups.” I know, it might sound like an exercise in buzzword-ery, but it's not. His talk was awesome and I'll do my best to summarize key points.
Even better than reading my key points, you can watch his entire talk here (it's no longer online), thanks to one of the event sponsors. You can also see this video that I blogged about last September.
Eric impressed me with a well-thought-out, cogent, and intriguing presentation that showed a deep understanding of the lean philosophy — not just a bunch of tools or new buzzwords being applied to startups, in particular software development. His ideas apply mainly to web-based software startups, so I'll use “startups” as shorthand for that, although some of the ideas would be pretty universal, I think. Eric says these ideas apply best when there's market risk, as opposed to technological risk. By “market risk,” the question is “should it be built?” not “can it be built?”
Just as many people think lean doesn't apply to healthcare (“we're not a factory!”), many would also assume that lean is suited for big, established, slow manufacturing companies. But Eric made the case that process is not equal to bureaucracy. Process means discipline, which can be a good thing. For example, his second startup had a “world-class” onboarding process, where new engineers were shipping code the very first day. That sounds like a case where process, “standardized work” even, had benefits for the company.
One of his key themes was that the best startups are those that iterate their code and product rapidly and allow their core business direction to change based on customer needs and what the market is telling them. The point at which a company changes direction based on the market is what Eric calls “The Pivot.” The “iterate rapidly” idea reminds me very much of Steven Spear's point in his book Chasing the Rabbit, that nobody ever designs a perfect system, what matters is how quickly you learn and “PDCA.”
Eric's first startup was a classic product-out company. They had the perfect idea (so they thought), so they spent a lot of money, took a lot of time — and at the end, had no customers. I'm paraphrasing, but he quipped,
“We could have gotten the same result by just opening a website to take orders before we ever worked on the product.”
At least they would have realized quickly and cheaply that the idea wasn't going to work. That first startup was using the “one big swing” approach – and they missed. It reminds me of the story Newt Gingrich told about the Smithsonian's “big bang” approach to trying to build an airplane in an attempt to beat the Wright Brothers. Their one big swing sank in the Potomac when it failed.
With his second startup, IMVU, they took a much more iterative approach and a more market-in approach. They launched their initial product very quickly (just a few months, if I remember right). They had early adopter customers who were, basically, willing to tolerate a bad product that was “more likely to crash your computer than to work properly.” But those early adopters shared the vision and were willing to put up with that pain. The customers gave feedback and interacted with developers in a very public forum (some good transparency). The rapid iteration approach was also a winning strategy for the Wright Brothers, as Newt described. The Wright Brothers succeeded because their plane was tested over land and it was easily repairable (and improve-able) when it crashed and parts broke.
“Iterative” isn't new to the software world. I'm not an expert in this arena. but I have heard of the “agile” development model (and have lots of Twitter followers who do work with that methodlogy). Eric said “agile” was great for when your problem (customer need) is known and your solution is unknown. This works better than the old “waterfall” approach where it's assumed the problem and solution are known.
For a startup, the problem AND solution are both unknown. This is why lean and rapid iteration are good strategies.
The iterative cycle is shown in this diagram. You can see some similarities to a Plan-Do-Check-Act cycle (or maybe an OODA loop).
Eric gave examples of using the “5 Whys” problem-solving approach for problems like, “Why did the server go down?” He described the PDCA cycle of implementing a new idea quickly and quickly detecting if it was a “good change” from a “bad change,” being able to revert a bad change quickly and “stopping the line,” ala Toyota. With the code line stopped, nobody else checks in new code while there is problem.
As John Shook, of LEI, had blogged about, Eric talked about there's always a “social problem” behind any “technical problem,” like the server crashing. Lack for training, for example.
When the customer sees the failure, there are two actions, exactly the same as what I teach to hospitals:
- Fix it
- Prevent it from happening again
In the controlled experiments approach, Eric said “we're willing to make any mistake ONE time,” not firing or punishing anybody for that. But the problem would be repeating that mistake a second time, if the organization didn't learn.
People should be allowed to make mistakes, but find them, Eric said. Shorter development cycles allow you to find and fix problems quickly, while slower cycles allow you to hide problems (never a good thing, hiding problems). Making problems is less of an offense than covering a problem up. Reminds me of the Toyota-ism, “No problems is a problem.”
Eric also advocated looking at the big picture in a company, that you can accept local inefficiency for global efficiency. Measures have to support that global company view, as efficiency shouldn't be measured in the number of hours of time spent coding, or the number of lines of code written.
Eric's key metric: how much are you learning? How many experiments can you conduct per dollar?
Great stuff. I feel like I commented on a lot, but there are a lot of other nuggets, especially if you're interested in startups and entrepreneurship – the real source of job creation in our economy! Check out the video, it is an hour well spent. I will try to get him on for a podcast.
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
Great post Mark. I have been following Eric’s path recently and have become quite intrigued by it. His development process for start-ups is outstanding. However, I think some small businesses it could be misinterpreted as “flying by the seat of your pants” which is the furthest thing from it. It is all about engaging the customer and providing a vehicle to implement that knowledge. The similarities to PDCA are readily apparent.
Enjoyed seeing your take on the subject.
Hey Joe – yeah, you’re right there’s a risk that rapid experimentation would be an excuse to not follow a disciplined PDCA cycle. But Eric was pretty clear that you need data and measures, that this should be a controlled experimental process. I don’t think a “lean startup” would just let developers throw code out there without it being thought out a little bit. A software company I used to work for almost had the attitude that they “assumed” the new code would work. It seems the lean startup approach almost assumes it won’t work (or at least it tests quickly and often to actually verify – check – instead of just plan – do or, worse just do).
There’s parallels to hospital patient safety work, the book by James Nance (“Why Hospitals Should Fly”) where hospital staff assume there’s a 50/50 chance something could go wrong, so they are prepared to detect errors and address them immediately (while of course working to prevent them from happening again). Just quickly catching errors won’t be low cost / high quality if those catches don’t lead to root cause problem solving and prevention.
Great summary, and having to listened to Eric talk a couple times online, I think you captured it well.
As his ideas are articulated, they apply mostly to software startups. But the ideas behind it apply more broadly. They can apply to the local corner market startup or the specialty-product store / catalog startup.
All of this comes to being a learning organization. The iterate code is PDCA on a tactical basis. The “pivot” is PDCA on a strategic or hoshin kanri basis.
[…] well, along with some good reader comments. Eric Ries, of the “Lean Startups” approach, also emphasized how important it is to not blame software developers for a problem, as that interferes with […]
[…] Notes on a Talk by Eric Ries on “Lean Startups” dal Lean Blog di Mark Graban: Le startup lean spiegate da Eric Ries con ottimi commenti di Mark Graban (traduzione automatica) […]
Hi Jamie,
I am quite positive the lean startup approach applies to any startup. The patterns that go with getting a startup on the line and running are pretty much the same everytime.
In the beginning there is an idea that improves something in life.
There are potential customers.
The idea and its value is seen by small amount of early adopters, mavens and visionaries.
Learning from quick and small actions/interventions into the existing market situation and the startup entrepreneur learns quickly step by step.
Start small and fail quickly and often (in small scale).
Success will come up;-)
What is the experience of entrepreneurs?
Cheers, Ralf
.-= RalfLippold ´s last blog ..Higher Purpose of own Action – What is driving us like devil? =-.
[…] is my earlier blog post about seeing Eric speak at MIT late last year. Here is a recent video discussion where Eric is interviewed by Robert Scoble […]
[…] been a fan of the “Lean Startups” work of Eric Ries since last year, so I’m happy to be producing a free LEI webinar called “Lessons from Lean […]
[…] example, Eric Ries talks about not blaming software developers and using PDCA improvement cycles in his “lean […]
[…] knew this would be a great learning adventure. After learning about “Lean Startups” at talk by Eric Ries in late 2009, I found another new way to stretch my Lean thinking (leading to my involvement with a startup, […]
[…] Measure – Learn” (as a loop similar to PDCA/PDSA) – see this photo I took at his MIT talk in late […]
[…] been intrigued by the “Lean Startup” movement since I first saw Eric Ries speak at MIT back in late 2009. I’ve read his book The Lean Startup, have attended a bunch of the conferences (speaking at […]
[…] I first heard about Eric and the Lean Startup movement in late 2009, before his book was published. I wrote a blog post with my impressions here. […]
Hi Mark,
You posed a question whether others used a different tool before 5Whys. Standard problem solving practice for us is using 5W1H to clearly define the problem before asking why.
Cheers Doug