Here is a sample subscription for you. Click here to start your FREE subscription
- Eric Ries on lean start-ups (MIT talk on 11/19)
- Learning by failing...
- The art of pitching and presenting
- Rich Miner @ MIT
- Joe Hadzima @ MIT
- More Recent Articles
- Search An Entrepreneur's musings
Eric Ries is here at MIT courtesy of the 100K competition and is addressing a sizeable crowd in 32-123. A predominant chunk of the audience consists of current and aspiring entrepreneurs. I am blogging live.
First slide reads: Most startups fail. No big surprises here.
Next slide: The pivot - what do successful startups have in common?
Pivot is the ability to change directions quickly. The difference between a successful and an unsuccessful start-up is the number of pivots a start-up makes before it dies.
Next is a story of 2 start-ups. Start-up 1 invited Eric to interview. When he arrived at an unmarked located in the middle of nowhere in Silicon Valley, he found a banner that essentially said "we can't tell you what we build, but we can tell you who works here. In start-ups, it's all about the team!".
Strategy of the company was to build a world class technology platform with a compelling long term vision. They raised plenty of capital, hired the best and the brightest, hired an experienced management team, and created buzz in the press and the blog-sphere.
The outcome: the company failed, $40M and 5 years later.
Why did this company fail? Two words: shadow beliefs.
Shadow belief #1: We know what customers want.
Shadow belief #2: We can accurately predict the future. The company had gained a lot of momentum in a particular direction, which made it very difficult to pivot.
Shadow belief #3: Advancing the plan is progress.
Next, is the story of startup #2 called IMVU. Here is what IMVU did differently:
- IMVU shipped its first product in six months, albeit a horribly buggy beta product. Almost nobody used the software.
- Charged from day one. This allowed them to enter into, and maintain a regular dialog with their customers.
- Shipped multiple times a day (by 2008, on average 50 times a day)
- No PR, no launch
Asked themselves: what is the riskiest assumption we've made and how can we test it quickly? In their case, will people pay real money for a virtual avatar?
Results in 2009: profitable, revenue > $20MM
The lesson to take-away is lean start-ups go faster.
Plug for Steve Blank and 4 steps to Epiphany, see my first and second posts from 2 years ago on Steve Blank!
The talk's now focussing on customer development for start-ups...
Eric recommends two teams for all start-ups: a problem team, and a ? (sorry, lost this part multi-tasking. if you attended the talk, post a comment with the answer please?)
Minimize total time through the loop: ideas -> build, code -> measure, data -> learn... ideas -> build
How to build a lean start-up:
- Continuous deployment.
- Tell a good change from a bad change quickly
- Revert a bad change quickly
- Work in small batches (at IMVU, large batch = 3 days worth of work)
- Break large projects down into small batches
- Have a cluster immune system
- Run tests locally. Everyone gets a complete sandbox
- Continuous integration server - tests to ensure all features that worked before still works
- Incremental deploy - reject changes that move metrics out of bounds
- Alerting and predictive monitoring - wake somebody up if metric goes out of bounds. Use historical trends to predict
acceptable bounds.
- Conduct rapid split tests: A/B testing is key to validating hypotheses
- Follow the AAAs of metrics: actionable, accessible and auditable
Ok, at this point, I got to admit that some of the above points has me scratching my head at its obviousness. All these steps from what he calls "sandbox", to "cluster immune system", "incremental deploy", "alertive and predictive monitoring" etc. are STANDARD practices we follow in semiconductor chip design!
We call this "regression testing", and use a standard test bench comprised of carefully generated test vectors to make sure existing functionality isn't broken with new code that's checked in, and of course everyone gets a local sandbox to play in without affecting the source code! That's the only way to do it when designing complex systems! I was therefore a bit bemused to see the same thing being described as though it's a new practice for software design. Software folks, tell me, is this new for you guys or was I missing the point and Eric was merely stating what all techies knew anyway for the benefit of the non-technical folks?
Perhaps Eric is going to touch upon this - it's standard practice in chip design to not only run a subset of tests to test key functionality before checking in new code, but to run a bigger subset of test vectors overnight to make sure all of the code checked in that day does not break something, plus we run a mega set of vectors over the weekends when they can run 48 hour sims uninterrupted, to make sure we didn't break the tiniest part of the chip in the process of making changes... is software design methodology very different?
Unfortunately, my laptop is running out of charge at this point with nary a power point is in sight. If you have notes from the talk you will allow me to share here, shoot me an email!
As a big fan of the "failure-is-okay-as-long-as-you-learn-from-it" mindset, I thoroughly enjoyed this post by Steve Blank on the Cafepress VC pitch:
http://steveblank.com/2009/11/12/“lessons-learned”-–-a-new-type-of-vc-pitch/
"I joined the board of Cafepress.com when it was a startup. It was amazing to see the two founders, Fred Durham and Maheesh Jain, build a $100 million company from coffee cups and T-shirts.
But Cafepress’s most memorable moment was when the founders used a “Lessons Learned” VC pitch to raise their second round of funding and got an 8-digit term sheet that same afternoon.
Here’s how they did it.
Fail Fast and Cheap
Fred and Maheesh had started 9 previous companies in 6 years. Their motto was: “Fail fast and cheap. And learn from it.” Cafepress literally started in their garage and was another set of experiments only this time it caught fire. They couldn’t keep up with the orders.
Tell the Story of the Journey
The company got to a point where additional capital was needed to expand just to keep up with the business (a warehouse/shipping center collocated with UPS, etc.) Rather than a traditional VC pitch I suggested that they do something unconventional and tell the story of their journey in Customer Discovery and Validation. The heart of the Cafepress presentation is the “Lessons Learned from our Customers” section. ...."
I had an opportunity to hear an awesome lecture last week by Ken Zolot in 6.078. The topic of the class was pitching and presenting. Ken started with "Zolot's law of three nines". Per the law, Ken explained it takes 9 seconds for a person hearing the presentation to develop a gut feel, 90 seconds to hear an elevator pitch and 9 minutes to get the gist of the presentation.
I picked up several very useful tips:
- The well written headline must be terse yet descriptive
Example of a good headline: "Yahoo's profits triple despite sales decline"
Example of a bad headline: "Something went wrong in plane crash, experts say"
- Slides distract the audience from what the speaker is saying. To get the audience's undivided attention, blanking the screen is a good idea. The keyboard shortcut to mute the screen is "b" (blank the screen?)
- If the slides in a ppt are numbered, simply key in the page number followed by enter to jump to the slide. Not only does it make navigation easier, it conveys the impression that the speaker is an expert on the subject matter if they can jump to the right slide, without needing to scroll through and scan each slide.
- Skip the table of contents and use an executive summary instead.
- Be aware of what's on the screen during breaks and Q&A. Use this opportunity to display slides that could not be presented within the time constraints of the main presentation, and perhaps strategically nudge the conversation in the right direction.
- Anticipate questions and discuss them before they're vocalized. This makes the presenter appear knowledgeable and thoughtful, and lends extra credibility. For example: "One question you might have at this point is.... what we did to address this is..."
- Know how to say "I don't know" gracefully, and never say "it depends" which is a typical b-school response. One way to do this gracefully is to say "We haven't explored that option yet".
- Margin analysis is a great way to share information about cost advantages from multiple sources over a competitor's operations. It's much easier to absorb, and makes for easy comparison.
Rich Miner of Android - Google fame spoke to us at Founder's Journey on 10/13. It was a lively discussion on the future of Android vs. other platforms, and the stakes riding on Android's success. It was followed by a Q&A session, some of which I managed to capture below:
He was asked why Google does not build cell phone handsets. He responded "Our goal has never been to monetize handsets or Android. Instead of one perfect handset, consumers will have a pretty broad set of excellent handsets. If we can achieve this, we will have succeeded." Quite a contrast to Apple which perfected one widely acclaimed handset. It's a very different mindset - one vs. many, closed to the point of being paranoid vs. fully open, seeking complete control over the user experience vs. come, build and make the experience what you will, lock in with a single carrier vs. freedom to choose your favorite carrier and handset...
When asked how does one know they're a bright entrepreneur with a compelling case, Rich's instant response was "if you don't know that about yourself, you're not going to convince anyone else of it". Well said! He then expanded on it: "We never fund ideas, we fund teams we believe in. The teams we choose to fund have a decent idea that is defensible, that they can get to market, in a reasonable amount of time".
Some other thoughts Rich shared:
- In order to build a capital efficient business, the key is to assemble the right founding team so the idea can be moved along as far as possible before money needs to be raised.
- When the business model is unknown, present an investor with different options - a systematic and realistic process for how you are going to evaluate each opportunity to zero in on the business model that's the best fit or the company.
- When deciding who to raise money from, think of geography (VCs have strong local network), and expertise within the firm.
- On the value of east/west coast start-ups for a web/IT company, it is eventually a personal decision, combined with a knowledge of how effective you can be with your own network.
The constant refrain was "Know thyself!" - whether it be self-confidence in one's capabilities and ideas, knowing the markets and industry one's trying to play in, or, knowing what it takes to assemble a winning team.
Joe Hadzima visited us at Founder's journey on 09/30. One piece of wisdom he shared particularly intrigued me:
One reason companies fail is because they raise too much money too soon.
He explained that too much money encourages hiring mistakes - overstaffing with people with a specific skill set, which is not what is required for taking the eventual product to market. He also pointed out it causes unnecessary dilution, and distracts from the goal of selling to customers as quickly as the company can when a company is overly cushioned.
I had not thought about potential hiring mistakes as a fallout of too much money, so this was eye opening to me.
More Recent Articles
