The lean startup movement is growing and all over the world local user groups are meeting to discuss, learn, and build successful businesses. But what is a lean startup? Is it two hackers in a garage, or is it more?
According the Harvard Business School:
A dozen years ago, it seemed like all it took to launch a successful technology company was a vague idea, a PowerPoint presentation, a trade-show booth with a sexy spokesmodel, and a URL. Then the dot-com bubble burst and investors got wiser and warier. Gone are the days when entrepreneurs could spend years burning through venture capital while they figured out their strategy. These are the days of the lean startup.
"Most startups fail not because they can't build the product they set out to build, but because they build the wrong product, take too long to do that, waste a lot of money doing that, and waste a lot of money on sales and marketing trying to sell that wrong product," says Tom Eisenmann, a professor in the Entrepreneurial Management Unit at Harvard Business School. "It takes a lot of time, time equals money, the money runs out, and the startup fails painfully."
So lean startups are those startups that take lean principles and create a startup singularly focused on customer value and learning from customer feedback as soon as possible. Wikipedia tells us:
Lean Startup initially advocates the creation of rapid prototypes designed to test market assumptions, and uses customer feedback to evolve them much faster than via more traditional software engineering practices, such as the Waterfall model. It is not uncommon to see Lean Startups release new code to production multiple times a day, often using a practice known as Continuous Deployment.
Lean Startup is sometimes described as Lean Thinking applied to the entrepreneurial process. A central tenet of Lean Thinking is to reduce waste. Lean Startup processes use Customer Development to reduce waste by increasing the frequency of contact with real customers, therefore testing and avoiding incorrect market assumptions as early as possible. This approach attempts to improve on historical entrepreneurial tactics by reducing the work required to assess assumptions about the market, and to decrease the time it takes a business to find market traction. This is referred to as Minimum Viable Product.
Last week, there was a lean start-up conference in San Francisco that was showed at over 100 remote meet-ups around the world in real time and you can catch the talks on Justin.tv. Chris Matts briefly shared his views on the Agile_BA_Requirements usergroup:
I caught a couple of the talks and the message seems to be that the lean start up approach applies to any company facing uncertainty. Its not just about two geeks in a garage hacking out code but relates to major corporations as well. One of the stand out techniques is hypothesis testing. Testing your business model using a hypothesis as soon as possible. If necessary, you pivot your business model.
And Prashant Ghandi shared his favorite talk:
If you have to watch just one talk, then I'd recommend watching Steve Blank's 30 minute talk on how he intends to change the board meetings ( in reality changing the metrics that they look for). This relates to the hypothesis testing that Chris mentions. He is using this model at the course he teaches at Stanford and has validated the approach with VCs and Private Equity folks.
Agile and lean techniques continue to spread out of software development into the business world and more. What experiences have you had with lean startups? Are there lessons that we can take back into the software development world?
Then, how do you cross the chasm?
I'm project leader of OpenXava, in OpenXava the user community did not start to arose until a year after of the first release, and the code contributors until still one year more (currently there are 50 code contributors). So, lean startup technique had not working in my case. Yes, an open source project is not like a commercial product, is it?
Some things need some time
Re: Then, how do you cross the chasm?
I guess there are two ways to look at it:
1) Let's fail fast. Invest as little as we can, and get an answer to 'will people buy?' as quickly and cost efficiently as possible.
2) I believe in my idea and I'm going to give it every single ounce of my energy until it succeeds.
So Javier, you obviously succeeded with your venture. Did you do so because you did things slowly and were able to be patient with success? Did you go all-out and get early feedback from anyone saying that OpenXava has promise? Or did you just believe in the project and never give up until it succeeded?
Re: Then, how do you cross the chasm?
I think there are different ways to define success in software projects, especially when it comes to open source projects (as Javier mentioned). This is also influenced by the motif to start a project and therefore defines how big your "chasm" is and where it is on your calendar.
success = user acceptance:
when you're looking for growing amount of users accepting the software for its quality and usefulness, but the point of break even might not be in the near future. This mostly applies for community driven respectively non-profit projects.
success = ROI:
when you're looking for the fastest way the point when your product is finally making money.
However, from my expierience developing community driven project and company software projects, you should always lean on user's feedback as soon as possible! It's like planing sprints in scrum: as a developer you might think you know what's important, but the user always knows better what he really needs! The earlier you take that into consideration the earlier you'll reach a mature level with your product.
Re: Then, how do you cross the chasm?
Exactly! For me the goal is "user acceptance", indeed I didn't consider ROI until recently, and only as a tool, not as the goal
> you should always lean on user's feedback as soon as possible
I agree with you completely. But in order to have "user's feedback" you first need a user base, and sometimes the user base requires time to grow. Because, most developers wouldn't choose a framework for serious development if it has not already a good user base. So you have to wait...
Anyways, I think that lean startups idea (or pretotyping) is good, in fact possibly I'll use it when I'll develop a commercial product. I only said that it cannot be applied to all cases, because it could be counterproductive.
Interesting questions. Thank you for the food for thought! As a Lean manager and CEO, I do think that Lean lessons can be taken back to the software development world, including lessons from established companies, not only startups. Agile development and Lean manufacturing share several key traits. I think Lean managers can learn from Agile software developers, and vice-versa. Perhaps knowledge exchanges can be conducted through tours and executive meetings of the minds. An intriguing idea to explore, certainly.
I have been giving this topic much thought myself recently, and am publishing a post on my own blog about areas of overlap between Agile development and Lean manufacturing. If the lessons of both can be applied to both types of businesses, they will see success.
Peter Anthony, CEO, UGN, Inc.
Lean startup could be a framework competing with MBA.
Here is my blog:
Getting Fresh Knowledge of Lean Startup Fundamental