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!

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. ...."

Monday, October 26, 2009

The art of pitching and presenting

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.

Tuesday, October 13, 2009

Rich Miner @ MIT

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.

Wednesday, October 7, 2009

Joe Hadzima @ MIT

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.

Wednesday, September 23, 2009

Paul English @ MIT

Our speaker at Founder's journey this week is Paul English, one of the co-founders of Kayak. He started out with a brief biographical sketch.

Kayak is the 4th company founded by Paul. He was introduced to his co-founder Steve Hafner of Orbitz by Joel Cutler at General Catalyst. Steve pitched Paul over a couple of beers. Steve knew the travel business and Paul knew technology, and neither were experts in the other's domain. Paul used this to make the point that when you meet someone, if you have instincts that this would be a fun person to work with or has the skills you don't, learn to listen to that instinct and act on it!

Paul then touched upon the topic of hiring people. He mentioned that his strategy is to *always* be recruiting. He is always tuned to "who has that thing I am looking for?", and keeps an eye open always. This sounded like excellent advice to me. Self-awareness is a must, especially for entrepreneurs who need to hire to complement their strengths, and I have long since learned never to underestimate the role of serendipity in entrepreneurship. So this piece of advice really spoke to me.

When Paul hires people, he looks for 4 things:

1. Bandwidth - people who get things the first time, can handle curve balls and are intellectually intense.

2. Attitude - people who are focussed on winning, with the focus tempered by humility, a hunger for excellence and genuine curiosity.

3. Experience - people with expertise he doesn't have. They don't necessarily need to have experience with the task they are being hired for, but as long as they have the bandwidth, attitude and a complementary skill set, they will be considered.

4. LODB - Lack of Dysfunctional Behavior. When employees start at Kayak, they need to promise Paul 2 things (a) be the best in the role they sign-up for, and (b) be an energy amplifier. I loved this, and this is the second time in my life I've heard this advice.

The other person who gave me this advice 9 years ago is someone I revere as a technology guru who personifies both virtues. These people bring out the very best in the people they're around, and inspire others to try and mirror their excellence and energy amplification. Brady Keays, thank you for your excellent advice to a young engineer nearly a decade ago. It has served me very well. Thank you Paul, for reinforcing the message!

When an employee promises Paul these 2 things, Paul in return promises:
(a) he will make the person more productive than they have ever been before and (b), When they look back in 20 years, Kayak will be the best job they've ever had in terms of fun, work environment and job satisfaction.

Paul succinctly summarized the importance of LODB (Lack of Dysfunctional Behavior) when hiring: Better to make a mistake and lose a good person than make a mistake and hire a dysfunctional person. The dysfunctional person will pull down the team.

On the topic of integrating a new employee into the company, Paul shared his philosophy: "If you have a really strong group of employees, a new hire maybe shy. So for the first 30 days, our team focuses on what they can learn from the new hire first before the new employee becomes used to the group's ways".

He then talked about the red phone in Kayak's office. Per Paul's description, this is a big ugly red phone with a loud and annoying ringtone. When a customer calls kayak, one of the engineers has to answer it and is forced to directly connect with the customer. If there's a bug, it's a great incentive to fix the bug before one more customer calls with a complaint! There's nothing like connecting an engineer with his customer to produce a quality product.

Paul's final piece of advice was this: founders can fall in love with their ideas and ears can become deaf to criticism. Therefore, it's good to put out an early prototype and have it trashed, rather than trying to build a perfect product and getting it out to customers. Mark it clearly as beta, and your reputation will be intact. Do not sell a final product you are not proud to stand behind.

That capped an evening filled with multiple nuggets of wisdom.

Thursday, September 17, 2009

Chris Hughes @ MIT

Chris Hughes was at MIT on Monday, 09/15 addressing the "Founder's journey" class. He is the co-founder of Facebook and the brain behind the Barack Obama campaign. His visit was a hit among the students, many of whom related to him and the pressures he experienced building Facebook out of a Harvard dorm room. He was very engaging and had these great nuggets of wisdom to share:

When Chris, Dustin and Mark created Facebook, their goal was not to build the biggest website in the world. They started with brainstorming for a product they would all use themselves. He reiterated that it's about passion, a desire to build a great product, and not about the metrics or the money. He offered this advice to aspiring entrepreneurs:

- First, know what you are doing/working on. Second, make sure there's a need for it. Then, focus on it. Per Chris, the conversation inside Facebook was "How do we make sure the product is the best it can be for first, our end users, next, people who want to use our platform for marketing and advertising?"

- Don't get caught up in the formalities. He made it clear that he's not advising people to ignore the formalities (company incorporation, legal paperwork etc), but instead to understand that you will get caught up in it, and to be conscious of the fact that other, potentially more pressing matters, demand your attention.

- Value iteration and analytics. Chris provided an example from the Obama campaign: His first step was to understand what it was they were building. He was a newcomer to politics and like most of us with no political backgrounds, thought of TV related advertising when he heard "GEO TV" (it actually stands for "Get Out the Vote!"). He then set out to educate himself and started by clearing the slate and brainstorming. When he was short-staffed in the early days, he reacted by breaking up a big task (building the technology for the Obama campaign!) into the smallest possible pieces and tackling them one at a time.

For instance, the team first built the technology to publicize individual events, then the technology to publicize the events to different groups, and scaled from there. The focus was always on who's buying the product, who's using it, and how they are using it. On the donation page, the team tried several design changes such as the wording, the shape and color of the donate button etc. The iterations were rapid and repeated, until the team settled upon a version that increased the donation amount by 8%!

- Hire smartly. Chris advised hiring people who are smart, whose work and style you respect, are interested in your product, and are available to hire. He recommended going with the gut feeling whether or not a person is right for the job. If the feeling is one of indifference, his suggestion is to not hire them unless one's desperate!

- Don't let money distract you. Enough said.