"Plan B"

We met with Randy Komissar again from Kleiner Perkins. He talked to us about a framework that startups should use to make a lot of progress quickly. His working title for the framework (and book that he is writing) is called "Plan B."

The process works like this: the founding team should identify all relevant analogs and "anti-logs" for the new opportunity that is being explored. Analogs are examples of successful companies--not necessarily from the exact same space, but relevant enough that we can glean lessons applicable to our opportunity. The "anti-logs" are companies that were not successful. We want to draw upon the experience of others before us to identify the "knowns" regarding the given opportunity.

Then we identify the unknowns, upon which we wish to take a "leap of faith." These leaps of faith are pivotal for the start-up, and they are where the company should be focusing all of their efforts.

To address the leaps of faith, the startup should follow a 5-step iterative process.
1. Identify what the key questions are that need to be answered regarding the leap of faith.
2. Develop hypotheses regarding each of the key questions.
3. The company should go out and do testing to validate or invalidate the hypotheses.
4. Interpret the data from the testing to generate insights.
5. Refine the original hypotheses based on the insights from the testing.

Iterate steps 1-5 until you have resolved most of the key questions/leaps of faith. Once you have done that, you will have backed into a business plan which you can then execute.

Seems like a pretty simple, straightforward process? The challenge in executing this process well lies in the judgment that needs to be applied at each step.

• What analogs/anti-logs do you select for comparison?
• What are the most important leaps of faith? What are the key questions that need to be answered?
• What are the hypotheses for each key question?
• How do you create and execute the tests to validate the hypotheses? How do you run the tests as quickly and inexpensively as possible?
• How do you interpret the results, and what insights do you draw?
• When do you refine your hypotheses, vs. when do you throw out your test results and try again?

The most successful companies, according to Randy, can get through the process quickly because (1) their hypotheses are usually correct, so they don't have to spend a lot of time and energy iterating their hypotheses; (2) the hypotheses that are wrong fail early, fail often, and fail quickly. So you have to have the experience and judgment to develop hypotheses that are mostly right, and/or you have to be lightning fast with your iterative testing and have your hypotheses fail quickly up front.

Randy then took us through the example of Steve Jobs and the iPod. Jobs had a few different analogs: (1) the Walkman (people were willing to listen to music on headphones in public places), (2) Napster (people were willing to download and share digital music), (3) VCRs (media industry had to settle for "fair use"). He also had a couple of anti-logs: (1) The Rio (a poorly designed MP3 player), (2) Napster (got sued by RIAA because the record labels felt they encouraged pirating). He knew that people would listen to music on-the-go, and that they craved digital music. He also knew that he could design a much better user experience than the Rio, and he could create an ecosystem that would be friendly to the record labels. His biggest leap of faith--would people be willing to pay for digital music? Jobs didn't believe that they would. So what did he do? He hedged his bet. He decided that he wouldn't make money off of music, but off of the hardware. He created a "fair use" case by charging money for the legitimate music, but he also enabled users to download pirated music onto the device as well. The result? Only 3% of music on iPods was actually purchased from iTunes. But the record companies weren't able to sue Apple, and in fact, they cooperated with them.

Marc Andreesen's Blog: Startup advice

I just discovered Marc Andreesen's blog. There are a number of interesting posts here about doing your own startup. One post was about what VCs look for when they invest in a company. The second was about how to get to know VCs. And the third was about the most important thing for a startup.

What do VCs look for in a company?

• Founder risk - right founding team for the opportunity?
• Market risk - is there really a market for this?
• Competition risk - are there too many startups/incumbents in this space? Is this startup sufficiently differentiated?
• Timing risk - too early for this? Too late?
• Financing risk - how much total capital will be required? How certain are we?
• Marketing risk - will this startup be able to cut through the noise? How much does it cost to acquire a customer?
• Distribution risk - are there certain distribution partners required? How will it get them?
  
• Technology risk - Can the product be built? Does it require fancy, new, unproven technology? Is it dependent on some other tech breakthrough?
  
• Product risk - can this team build the product?
• Hiring risk - what positions does the startup need to fill into order to execute this plan?
  
• Location risk - is the team not located in Silicon Valley?

How to get to know VCs?

• VCs work through referrals
• Work at a VC-backed startup, kick butt, get promoted, and network all the way

What is the only thing that matters for a startup?

• Out of team, product, and market--it's market.
• A great market (with lots of potential customers) pulls product out of the startup
• There's a concept called Product-Market Fit (PMF)--being in a good market with a product that can satisfy that market
• If you're Before PMF (BPMF), focus obsessively on getting to PMF. Most startups fail because they can't get to PMF before they run out of cash.

3 Phases of a Start-up

We met with Randy Komissar from Kleiner Perkins last week. He gave us a lot of valuable advice about the 3 phases of a start-up.

• Phase 1: demonstrate the value
• Phase 2: demonstrate options for scaling
• Phase 3: execute

Phase 1: demonstrate the value

In this phase, the start-up is trying to show investors that it has developed something valuable to customers. This phase is marked by a set of iterative tests designed to support or refute hypotheses about the business. Suppose I have an idea for a new business. That idea is really a hypothesis--that whatever I develop will be valuable to customers. I should come up with a prototype that I can begin testing with customers to validate that hypothesis.

The name of the game in this phase is to learn by getting real customer feedback as early and as often as possible. I run a series of iterative experiments where I test my hypotheses with customers. Each time I learn something from a customer, I should refine and tune my hypotheses. And my "business experiment" should be designed such that I am testing the core, fundamental elements of my new business idea as early as possible. That way, I learn early whether my idea, at its core, actually has value or is simply a waste of time. Over time, I can get into testing details of the idea (such as specific product features).

It matters less whether my hypotheses are right or wrong. What's more important is that I have hypotheses, and that I have the strength of character to accept real world feedback that supports--or refutes--my hypotheses. I want to fail early, fail often, and most importantly, fail inexpensively. Failure at this stage is really good. It means I've learned something and probably avoided costs. I want the feedback from customers that they dislike a planned product feature well before I sink costs into actually developing that feature.

You should strive to test your hypotheses in a "smart" way. You should brainstorm a list of potential hypotheses, and test them in order of likely success. This requires judgment, of course, but you can improve your chances of having good judgment by synthesizing input from experts and customers. By testing them in order of likely success (rather than randomly), you improve your chances of hitting on the right solution early (without burning through too many iterations, too much time, and too much money).

During this phase, I have the challenge of doing as many iterative experiments as possible, and tuning the hypotheses of my start-up idea, as cheaply as possible. That means that I should always be thinking, "What's the cheapest way for me to get the feedback that will tell me whether my hypothesis is right or wrong?" So I should defer committing resources--which means deferring hiring people and even building the product--until I know whether the hypothesis justifies the commitment of those resources. Try to engage potential employees on a contract basis rather than commit to hiring them during this phase. Build very lightweight prototypes of products to test with customers, until you've gotten feedback that justifies the commitment of development time and resources to the product.

You sort of know when you're ready to exit this phase of start-up development. You've been testing and iterating your product idea with multiple customers. You've now developed a pretty valuable prototype or product, and gotten a handful of customers very excited about your new product idea. You may have engaged a couple of customers to participate in a trial with your product. You haen't really generated significant revenue yet--in fact, you may not have any revenue at all. But you have some excited reference customers. Will blog about Phase 2 next time.