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.
Highlights:
- 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.
Part I:
Part II:
Click Send - Aaron Franklin's Blog 
Absolutely spot on!
Even if you consciously hold such thoughts in your mind, you design in iterations, I STILL find myself doing the same thing I set out to avoid! Planning too many ‘things’ at once, over complicating ‘simple’ features, over thinking (or even thinking about thinking) before I have even got something out to the USERS!
After reading such article, I now find myself reflecting…
* Ok, so, I cut down my current project from 16 huge modules to 8 micro modules? (cool) but out of those ‘8’ micro modules…
* Which module is the initial chosen ‘1’? 😛 (let alone) which singular platform shall I launch that chosen ‘1’ on
Why?
So I can get the chosen ‘1’ out and learn from the people using it! Once again, Sobering article..
PS: Good luck on your start up!
Great article.
I think people often forget that agility is the key feature. Being able to quickly adapt & evolve based on the feedback received.
One of the issue is that companies place too much weight on abstract metrics – page views, interactivity of the user on the page, etc – and not enough on the qualitative aspects of the customer engagement.
When we launch new features or betas – we have a live feedback approach – where we engage the user from the initial contact to the end of the session.
It’s a great way to make them feel part of what’s being built.