I keep hearing about “lean startups”, but I rarely hear more than the basic idea of starting with a minimal viable product and iterating quickly. The interview below of Eric Ries by Robert Scoble gives much more detail about the logic behind and practices of lean startups.
- It’s about building the minimal product to start, and getting customers to start using it. Incorporate their feedback, which may take you in a very different direction from the features you had planned. Great example: Twitter.
- “The Curse of Prevention”: When you anticipate a problem too much/try to prematurely solve it, not only do you waste a lot of time by solving a problem that might not arrive, scalability is messy.
- Sales, Marketing & Business -> The Problem Team. What is the problem we are trying to solve? Focused on talking to customers.
- Engineering, Ops & QA -> The Solution Team. Build the minimal viable product. What is the minimal amount of work needed to be done to test the first element of the product?
- Code is not progress. Learning is progress. It’s not just about milestones and deliveries.
- After features are shipped, don’t just move onto the next features. Check that the features you delivered were the right ones. After the code is done, evaluate if that task was worth doing in the first place.
A Lean Startup makes sense for many reasons. It allows you to deliver quickly. It gets the product in front of customers sooner, so that you can continue development with their input. It ensures you’re delivering the right features. And it ensures you don’t invest too many resources in an idea that nobody wants to use in the first place. For a startup that needs money, it means you have something to show investors sooner. And you can also argue that it’s a good marketing tool, since you engage power users sooner, and make them loyal by incorporating their feedback.
Eric mentions he works with teams who deliver as many as 50 releases a day. Robert asks if a company like Microsoft could change from deliveries averaging 2-3 years. The online services group at Microsoft has been releasing more and more frequently, but Microsoft could gain a lot by picking up some of these principles, especially in regards to point #6 above. Too often, my team saw features for the product we worked with not based on what customers were asking for (sometimes customers begged for YEARS). We would often see features released that had absolutely no value, but the engineering team still celebrated.
Right now, I am playing with a new roadmap for LazyMeter using the Lean Startup methodology.