The Lean Startup Talk by Eric Ries

By Jon Saints - 20 Aug 2009

Talk by Eric Ries at the Hotel Boulderado last night on The Lean Startup.

The talk was framed as a tale of two startups that he worked for. One was a failure the other was a success.

Startup #1 the Failure

On the surface the failure startup did everything right. They had a great business plan, the best team of people he had ever seen assembled, a well engineered product, and perfect launch publicity. The companies $40M failure was blamed on a set of “secret beliefs” that everyone at the company had but no one recognized outloud.

The “seceret beliefs” were:

That we know what customers will want: they spent 4 years building one big product that was going to change the way people used the internet. The product was perfect from an engineering standpoint. But they never got feedback from the market along the way. This may sound obvious now, but at the time 2001 this is how things where done. They had one release and not “pivot points” along the way to adjust their ideas to the demands of the market.
That we can predict the future: The team on startup #1 wrote a perfect business plan. They also executed it well. They judged their success through the 4 years of development based on how well they were sticking to the plan. Measuring success by sticking to the plan, assumes that the authors of the plan can magically see into the future and predict a path to success. No one can do this. Remember that just sticking to a business plan does not mean progress. The market may have moved somewhere else from when you wrote your perfect plan. Without feedback from it you will never know where it went.

What is real progress? We will talk about that later.

Summary: Startup #1 launched with perfect product, team, and publicity. But, they burned through their money before they had a chance to pivot the business to market feedback.

Startup #2 The success:

Very Simillar product to Startup #1 but… 10M in revenue 2007… much more now

Had a business plan (that went 6 months into the future instead of 4 years). Planned to release a Minimum Viable Product, no matter what state it was in, in six months of starting to write code. Good Team. No Publicity for first buggy beta terrible release. A few… 2 or three people actually downloaded and played with the release that was more likely to crash your computer than to work properly. They received invaluable feedback from these users. One thing they found was that the code Eric Reis had been working on for six months was a total waste. They were able to refocus his energy to other matters quickly. Now days, he recommends this feedback happen within a month or two, weekly, or even daily. 6 months is way to long now.

Another great success of Startup #2 was that they did not divide the team into departments. There was no support team, dev team, management team, HR, etc. Instead everyone was cross discipline. You could divide the focus of their work into two categories:

Those focused on delivering the product to customers and the market and bringing feedback back to their work
And those focused on taking the feedback and engineering solutions to it.

Startup #2 success also came from Continuous Deployment. He says they have created test coverage that allows everyone on the team to deploy to production servers new small incremental features up to 50 times per day. They try to have newbies deploy to production on their first day. This continual deployment process evolved over time, learning from mistakes one by one… but you have to make mistakes to learn from them. They do not do weekly or monthly releases. Small deploys allow problems to be isolated quickly instead of wasting a whole release on something that might need to be reverted anyway. Startup #2 practices regularly reverting to be sure their revert process is fast, as quick as deploy, and always works. Every time a mistake is made a test is written to address it and a the human cause of it is addressed in person, possibly with a group. They use SimpleTest, Selenium, and Nagios to build up a product immune system that detects problems before they go live, and that can heal and revert quickly.

Through startup #2, Eric learned his definition from progress in a startup company. Progress is “Validated Learning” on behalf of an employee. This should happen each day for each employee. The best way to achieve progress is to setup systems, processes, and culture that allows for validated learning to take place regularly, rapidly.

Finally Eric asked us to close our eyes and think of one thing we would like to improve at our current workplaces. That one thing he said should be done in one day. Think of it… plan it… do it tomorrow.

Here is Eric’s Blog: Startup Lessons Learned