Bob Metcalfe, a co-inventor of Ethernet and co-founder of 3COM and GP at Polaris Ventures is in 6.078 today to talk to us about selling.
The talk began with an excellent point - "nerds" have a disdain of the "suits". But one of the most frequent causes of doom in a tech. start-up is this disrespect. Three things that sink a company are the uncontrollable ego of the founder, lack of money and lack of focus.
He then went over the numbers at 3COM - for every $1 spent on engineering, $10 was spent on increasing sales.
First level of selling consciousness is the belief "build it, and they will come".
Second stage of selling consciousness is argument - go out and argue with people why your product is better than the competitor's. Frequently, you will win the argument, but will not get the order.
The third stage of selling consciousness is when you over-promise and under-deliver. Works better than second stage but is ultimately not too successful.
The fourth and ultimate stage is to learn to listen to customers, and hear what they are actually telling you. This will result in the maximum number of sales.
Caveat: If you are going to go ask customers what they want now, you are going to have to guess what they want 2 years from now, if that's when your product is going to be ready.
On how do you know when you're selling to someone who will never buy vs. someone who needs more convincing, the trick is to qualify the customer. 3COM survived versus competitor because they made a conscious decision to not network Apple computers.
Monday, November 30, 2009
Thursday, November 19, 2009
Eric Ries on lean start-ups (MIT talk on 11/19)
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!
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!
Tuesday, November 17, 2009
Learning by failing...
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. ...."
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. ...."
Subscribe to:
Posts (Atom)