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.
Don't want to miss a post or podcast? Subscribe to get notified about posts via email daily or weekly.