At the Amazon Lean Cloud conference at the Australian Technology Park, Eric Ries presented on The Lean Startup methodology.
On top of the interesting discussions generated by the Mr Ries, I was also lucky enough to score a free signed book ;)
Below are running notes from his presentation.
Startup = Experiment
Startups: turn ideas into code
We're still early in the startup phase of the Internet and we're still working out the optimal way to run these startups
Most startups fail but we can't use that to justify making the wrong decisions
Entrepreneurial Management: management that survives and can handle adversity
Pivot: change the startup's direction but stay grounded in what has been learned
How many opportunities do we have left to pivot → runway
Pivot: Driving your car off the cliff whilst positively mentioning the gas mileage
Learning & Feedback: Don't wait until you fail to learn something important, do it early and often
'You can drive faster if you close your eyes and put your foot on the accelerator' is equivalent to 'You can code and execute faster if you don't understand what you're doing'
For every pieces of advice, you can find a startup that did it and succeeded and a startup that did it and failed.
We need an accounting revolution
Everyone likes to talk about the process stuff from Toyota
Accountability: If you pitch FFF/VCs/... and get $X to spend in the next Y months, there's no guarantee on the quality of the product but there is a guarantee that by the end of Y months all the money will be spent.
For startups, the Brink of Success is indistinguishable from the Brink of Failure -- how can a VC tell them apart?
You know the % of customers sign up for service number in all those spreadsheets?
That's a leap of faith assumption that our entire company depends on
Not sensitivity analysis, it's gross failure analysis
No-one does this as it's bad news but it's better to have bad news that's true than good news that's made up
For each leap of faith assumption, do the least amount of work possible to find out what that number actually is
When improving bad software, making it easier makes it easier for customers to realise they don't want it
Pivot at the optimal time, not when the wall / ceiling / sky is falling in
Every six weeks, add a meeting to the calendar called Pivot or Persevere
If six weeks from today I need to sit in that meeting, what numbers do I need to push for either pivot or persevere? Is what I'm doing right now going to help with that?
Each company should be built to learn from the ground up. People in fifty years will laugh at how obvious all of this is.
Think big, stay small, scale fast
Interested in saying hi? ^_^