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:
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:
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