Review of the lean start up conference: “Start up lessons, San Francisco, April 23th, 2010”
I could not have found a better introduction for this blog than a post about revolutionary start-up building and product development concepts. Last week, I stumbled upon a tweet of @romainlacombe, a passionate entrepreneur I met in San Francisco, which sparked my interest. A conference in San Francisco was live streamed in the most tech innovations enthusiastic place in Paris @lacantine.
Multiple keynotes, case studies and panels were around a new entrepreneurship school I had never heard of: the Lean Start-up Movement. On paper, the invited speakers and start-ups were claiming disrupting management methodologies, dramatically impacting product development and getting impressive results. Should the panelists of this very promising program have used more or less superlatives, I would have still watched the simulcast to catch up with my friend and the excited atmosphere of the Silicon Valley entrepreneurs.
Actually, I could not have imagined that today, you might still be able to revolutionize thousands of companies proofed management rules, question 50 year used frameworks and demonstrate that creativity in organizations is not dead. EVERYWHERE, innovation will remain. Deep inside, you are intrinsically convinced but sometimes, you tend to forget and think that centuries long improvement processes have finally come to the ideal and most optimized state. Wrong intuition! You’re still somewhere in the middle of a learning curve that started way before you and still have a very long path down the road. And that’s what I realized during this conference.
Anyway, let’s cut this chatty introduction to get to the point. I hope I won’t fail to meet your expectations and make my description as compelling as the pitches were. I will dwell only on four of the speakers: Eric Ries, the father of the Lean Start up, Kent Beck, a well known engineer for his “extreme” programming techniques, Ash Maurya, and the case study of Wired Reach, and Aardvark founders.
Eric Ries – The Lean Start-up principles (Keynote here)
How to talk about lean start-ups without thinking about lean manufacturing? Where lean manufacturing aimed at responding to market demand and stock level uncertainties, lean start-up concepts address the high level of unpredictability faced by early stage companies. Developing (yet) unknown solutions to (yet) unknown problems is not the simplest challenge to solve. The only way to get through this is agility.
“Lean start-ups are not about cost. They are about speed.” is one of the myth/truth Eric Ries mentioned about lean start-ups during his presentation.
In traditional businesses, you may not ignore the well-known 3 steps loop: Build (Product development), Measure (Metrics introduction), Learn (Confront results and close the loop). In non-traditional companies such as lean start-ups, the 3 steps loop still applies. Wooo such a scam! I want my $760 ticket to be refunded! In fact, even if the loop remains, lean start-up goal (I would say obsession) is to minimize the total time throughout the loop. Where traditional project management allocates more resources and time to shorten the deadlines, bootstrapped lean start-ups have a different and brutal approach. No matter how “refined” your product is, it must get out of the door.
And Kent Beck pursued with more details.
Kent Beck – Agility and beyond (Keynote here)
With agile deployment, traditional engineering quality falls apart. Endless processes of building/measuring/checking/enhancing are purely over with lean start-ups. Your product is uncompleted? Your code is messy? Your design is dirty? Release it! NOW! WTF why??
At first sight, this rushed and excessive behavior conflicts the common engineering sense. Engineers are builders. They like building. Kent Beck said from himself: “I like building, I am builder and I will always be”. Designing well achieved, compelling, peers-recognized masterpieces is the purpose of their life. They are not ok with doing shit. And they would be not ok with peers joking or making fun of their code. In fact, engineers are quality extremists.
And quality requires time. The 20/80 rule of valuable time applies. 80% of the created value requires only 20% of the time. In other words, 80% of the time is valuable for only 20% of the project. And time is your enemy. Basically, you have spent hours designing, coding an application and without market confrontation, you still do not know what your customer really wants. You do not even know your future customers. This extreme level of unknown mandates your team to act and get user feedback quickly.
Agile deployment does not mean either “fucked-up applications”, “unusable software”, and “awful product”. It may be a little buggy. It may look a little weird. But it’s totally functional. Minimize time and maximize value is lean start-ups bottom line. As shocking as it may be for some kind of engineering perfectionism, it sounds perfectly balanced to me. Traditional development had remained excessively product-centric and agile deployment is simply moving the cursor toward a customer-centric approach. Agile deployment is revolutionizing software development as much as price-based pricing kicked cost-based pricing out.
Ash Maurya’s keynote was the first case study with Wiredreach. He explained how agile deployment practically consists and gave some AMAZING orders of magnitude.
Ash Maurya – Wiredreach case study (Keynote here)
Minimize the time gap between the build phase and the next build phase. How much exactly? Well, lean start-ups are not little players. Time gap between two successive product releases is purely divided by… something around 1000. You don’t update your application every 6 months. You do it every 30 minutes. You don’t wait to have a dictionary to commit your code lines. Every fifty lines, your code is on the server.
But how to prevent crashes? This inhuman frequency forbids any test! Well, you play it smart. You release your code locally to a limited amount of users. If too many errors are encountered, the code is withdrawn and patched for the next release… still 30 minutes later (even less). If everything is doing ok locally, the code is entirely deployed. Engineers had to slice the whole development in tiny elementary components to enable this 30 minutes frequency.
Ash Maurya told the audience it was pretty scary to take the plunge for agile deployment. But the need for feedback was visceral. Aardvark satisfied the same need by an even more innovative method. Like my buddies in the US said, “OH MY GOD”.
Aardvark or how far could you go to get user feedback? (Keynote here)
I am still admiring how bold these guys were. Aardvark is social search: their algorithm does not browse the web to index every single page of the Web like Google does. When you ask a question to Aardvark via an IM client (gmail, msn, …etc), the algorithm is looking for the right person in your social network (and the network of your network…) to answer it. Once the best “responder” is found and agrees to get in touch with the person who has a question, Aardvark gets both parties together. Apparently, it works very well.
And that was remarkable, especially at the beginning: as soon as the application got released, users pretty enjoyed the service. Aardvark algorithm was doing its job. In fact, at that time, no algorithm was running on the servers.
Aardvark founders had hired a bunch of guys to “fake the application”. In fact, these guys were simply doing what a basic information call center can do. You call the center and the nice operator tries to find your answer on the Web. But why did they do that exactly?
First answer: By doing this, Aardvark was building a user base. People started to use their service and were even enjoying it.
Most important answer: Developers were getting feedback. They were learning what users wanted, what disturbed them, who they were…etc. It was a ton of valuable information they could not have gathered by coding one year long under stealth mode.
Aardvark founders really made me lose my s***. This story proves that every problem (the most important one for start-ups: customer traction and feedback) can be solved. Sometimes solutions are very prosaic. Other times, they come out of over creative brainstorming sessions.
Now Aardvark is part of Google. It has been acquired for a few millions dollars.
And lean start-ups are about to have a significant influence in the management history.
