Though I had considered many times attending the Lean Startup Conference in San Francisco (12.9-11, 2013) over the past weeks, I was fortunate enough to find a Green Bay LiveStream host (thanks @rdkhatch for organizing) which allowed me to check out the conference virtually before spending a large amount of money on travel/hotel/etc. 
I plan to share info I picked up from the screencast sessions over the next few posts. I am not going to spend a ton of time attempting to define Lean Startup terms/etc with these note posts. I do expect to come back and do a few introductory posts on Lean Startup methods in the near future where those totally new to the topic can get themselves up to speed.
Eric Ries, the author of The Lean Startup book and host of the conference kicked off the day.
Eric states the lean startup looks very strong vanity metrics wise. He says there are lots of people jumping on the bandwagon now. It’s been two years since his book was released and five years of practicing the principles for him.
The question is, how are we doing as a Lean Startup community? Are we sharing/talking about the right things?
Lean startup: are we creating a new general theory of management? (Joke here about why talking about management… that’s not cool stuff!)
Remember: a startup is a human institution under uncertainty. Traditional management practices of planning, forecasting, and tracking progress to plan just doesn’t work in times of increasing uncertainty.
There are lots of ‘bumper sticker’ motto’s coming out of Lean Startup talks/etc. ‘Get out of the building’, ‘market disruption’, etc. That’s not the focus of this conference. It’s more than bumper stickers and buzzwords. It’s about the important stuff… the hard stuff…. Topics like:
- If an single employee in the company has an idea regarding how to innovate, or possibly improve efficiency, how does that idea percolate? Get implemented? Maybe even tested to see how it does?
- What is the process to get idea’s tested to see if they matter, make an impact?
- How do we simplify… ensure we are not overdesigning a product. (Example here of a microwave with 27 special action buttons… how many do you really use? 3? 4? Those other 20+ buttons took valuable time to build, test, etc… What a waste!)
- Who’s fault is it when we over engineer products? (like the microwave example above) It’s really nobody’s fault, the system failed and wasted peoples time and also potential.
- Do we have a routine and regular process to test and discover the ‘honest to god’ truth of whether it’s really going to make a difference or not?
More notes to come…