Jay Haynes

Market Sizing: Numerical Narratives

Chris Dixon posted about market sizing using narratives as opposed to numbers, and Fred Wilson agreed - even demonstrating market sizing with a cartoon illustration. 

It is easy to see why Chris' and Fred's "narratives over numbers" market sizing might be appealing. After all, as Brad Feld writes, "Almost every market sizing presentation is incorrect - by a lot. Enough to make it irrelevant." Chris writes, "you should never rely on quantitative analysis to estimate market size. Venture-style startups are bets on broad, secular trends."

This seems to make sense: tell a story because your numbers are going to be wrong anyway. But let's analyze the traditional market definitions to see why traditional quantitative methods are incorrect. Non-quantitative analysis (a story) is not enough. Market sizing has to be quantitative because it is a tool to make an investment (i.e. a quantitative) decision.

What is a market? The traditional definition of an "addressable market" is the problem. VCs and entrepreneurs use either technologies (e.g. search or semiconductors), products (e.g. insurance or printers), or users (e.g. app developers or gamers) to define markets. But these definitions are flawed because this is not they way customers think about markets. This flaw was recognized back in the 1960s by Theodore Levitt who famously noted that industries define themselves by the solutions (railroads, movies, oil), but they should be defined by customer needs (transportation, entertainment, energy). 

In contemporary language, markets should be defined by the jobs customers are trying to get done (e.g. store music), not by the solution (CDs, MP3 players). This makes telling a market size "story" much easier because jobs have a beginning, a middle, and an end, just like a narrative. And jobs are independent of any solution idea you may have. With the job as the unit of analysis, the market can be quantified with precision. We call the resulting number the "securable market" to distinguish it from traditional definitions. The inputs into the market size calculation are critical, and, surprisingly, they have nothing to do with the product or solution.

So, yes, market sizing should be based on a narrative, but it should be a numerical narrative. Otherwise, like traditional market sizing techniques, it is just a guess. 

Fail Fast vs. Zero Burn

Mark Suster has a nice post about the "fail fast" method. He rails against fail fast, and rightly so. He writes:

I have met so many young entrepreneurs who tell me, “we don’t need business plans anymore, there a waste!  We’re going to put our product out there and fail fast!”... or they tell me, “we’ll launch a bunch of products and see what works.”  That is the old “throw spaghetti against the wall and see what sticks” approach.  It’s intellectually lazy and I doubt many great companies are born this way.

We definitely agree with Mark's view. In fact our plans are extensive and they take time and money to create for one reason: the goal is to never fail. Of course most of the venture community (and the broader innovation community) thinks this is impossible, but as we have shown with over two-decades of successful product launches, it is possible by using scientific methods to understand markets and customer needs. The problem is not with the idea of creating a business plan, it is with the inputs to the plan. The inputs (i.e. the definition of a market and a customer need) have to change, otherwise creating the plan will not result in a higher chance of success.

In our model, we use what we call a "zero burn" model. In the traditional model capital is invested in overhead and development ("burn") to build and launch a product idea. The fail fast model just tries to accelerate this by launching multiple products with less capital, but the process is fundamentally the same. As Peter Drucker said, "There is nothing so useless as doing efficiently that which should not be done at all."

In our zero burn model, we do the work of selecting and sizing markets, uncovering all the customer needs (which is possible contrary to the mistaken "latent needs" school of thought), prioritizing all the opportunities, picking the right strategy and generating and validating a solution idea (i.e. a platform, business model and feature set). All of this work is one before development and before any investment in recurring burn. 

Why does this work? Because we use a different unit of analysis (jobs and outcomes) and rigorous quantitative techniques that can predict if there is product-market fit before the product is launched. It takes a lot of time, hard work, and capital to get it right. But it is essentially a business planning process designed to significantly reduce the failure rate. And it works. 

Top 12 Mistakes (3,4, 5)

I wanted to continue my analysis of Marty Cagan's Top 12 Product Management Mistakes. I already analyzed the first two mistakes here, and I included an introduction to our ODI terms. I think it is helpful to look at the rest of the mistakes and offer ODI-based solutions. 

Mistake 3. Confusing Yourself With Your Customer

Marty identifies the third mistake as thinking "of yourself as more like the target customer than you are." This is a good mistake to avoid, but there are two dimensions to this mistake. The first is the functional job that the customers are trying to get done. Without a detailed understanding of the job, all the process steps in the job map, and all of the outcomes, it is almost impossible to make sure that your solution will meet the customer needs. The second is the consumption chain jobs (install, interface, learn-to-use, maintain, etc.). In this mistake, Marty is really talking about the consumption chain jobs (the "usability" in Marty's terms). 

Confusing yourself with your customer is only part of the reason usability testing fails to uncover flaws in the product. The real reason is because the product does not satisfy the functional job and it outcomes. Customers don't buy product to interface with them or to learn to use them. They buy products to get a functional job done. So it is no surprise that usability testing, no matter how much of it you do, fails to prevent a flawed product launch.  What is needed is testing of the features against the outcomes in order to validate that the feature satisfies the functional job's outcomes. And because outcomes are metrics, satisfaction levels can be measured accurately. 

Venturesome Consumers: The v1.0 Mistake

I'm reading Amar Bhide's The Venturesome Economy and he mentions Apple's iPod as an example of "the venturesome spirit of U.S. consumers".  He quotes a WSJ article about Apple:

"Steve Jobs can introduce 'clumsy, overpriced, 1.0 versions[s] and trust that the army of several million Apple true believers will rush out and buy. That is the crucial, often overlooked, key to Apple's continuing success."

I could not disagree more. Apple's success is not based on clumsy 1.0 versions at all. This is a simplified explanation of why their products often define new categories, and this type of thinking is why entrepreneurs and venture investors think the "fail fast" strategy will work. Focus on the early adopters and iterate the product until it is ready for the mainstream. 

The problem with this analysis is it does not focus on the job that Apple helps consumers get done. Consumer jobs are complicated and each one has potentially 50-150 different metrics related to performing the job with speed, efficiency, and predictability. 

So why does Apple succeed? Because it focuses on the job the customer is trying to get done, and it is exceptionally good at identifying underserved jobs and satisfying the metrics (the outcomes) related to getting the job done. Think about the jobs they addressed with the iPod: storing music, listening to music, finding music, organizing music. The reason iPod v1.0 was successful was not because "true believers" bought it. It was because it got those music related jobs done better. 

I still use my v1.0 iPod as a music storage system for my car. And in 2009 it still works as well as it did when I bought it because Apple helps me get the job done better.

Why Apple Wins: It's the Job

Apple's winning streak over the past decade (OS X, iPod + iTunes, iPhone) is based on helping customers get jobs done better. Of course, their user interfaces are legendary, but customers don't buy products to interface. They buy products to get functional jobs done. 

This iPhone ad is a great example. The focus is on the jobs you can get done.

93% Chance of Getting It Wrong

Traditional startups are constantly iterating their strategy to find one that works. So it is no surprise that business plans are a waste of time for fundraising. VCs are really investing in the people, as they will readily admit. But it turns out business plans are a waste of time for product development as well. I have been looking for data to support this, and I finally found it. 

A study done by Amar Bhide, found that 93%(!) of successful startups reported that "the strategy that led to their success was largely different from what they had originally planned."

So now we know: a strategic plan won't get you funded and it won't lead to a successful product. What is an entrepreneur to do? There are two possible conclusions. 

First, get rid of planning altogether and just wing it. This is the fail fast strategy: build and ship quickly and cheaply to see it anything sticks. By definition this strategy will only work if you can make more bets and hope that a few win. In other words, this strategy doesn't change the success rate, it just changes the number of bets and hopes a very small number of successes make up for all the losses. It is basically a lottery. See Y Combinator and Tech Stars. 

The second option is to fundamentally change the way strategic planning is done. From the perspective of the entrepreneur, this is the only option because starting and running 20, 30 or 100 companies is not possible. The starting point has to be a different unit of analysis for strategic planning. And that unit of analysis has to be the job the customer is trying to get done. 

Why Virtual Is Real: It's About the Jobs

Bill Gurley has a great post about monetizing social networks. He analyzes TenCent, a Chinese IM company, and uses virtual world examples to demonstrate how social networks could monetize their huge base of users. The model has a few different names: freemium, digital item, micropayments. The New York TImes also has an recent article on digital goods.

Bill writes: 

It is my perception that most U.S. executives have trouble conceiving and believing in the digital item model. For starters, they simply think it’s strange. “Why would someone buy clothes for their virtual avatar? That’s weird.” What they fail to realize is that U.S. consumers pay for “virtual” things all the time.

And he gives a good example of consumers buying brands that are basically virtual, i.e. non-functional. For example, the willingness-to-pay for a pair of Channel sunglasses drops significantly if the Channel logo is removed. "People are buying an image" because they "care greatly about how they want to be perceived."

So yes, customers do by products that project an image about themselves in both the virtual and real worlds. In other words, they have emotional jobs that they want to get done in both worlds (and these jobs can be personal or social). 

The crucial distinction is between the functional and the emotional jobs, not the physical and the virtual worlds. In both worlds customers will need to get functional jobs done to accomplish goals and complete tasks, and they will need to get emotional jobs done (personal jobs to improve how they feel about themselves and social jobs to improve how they are perceived by others). 

If social networks want to analyze the opportunities for monetization, they need to focus on the functional jobs for two reasons. First, because these are the jobs that customers are more likely to have a willingness-to-pay for, and second, because it is much harder to consistently build solutions to satisfy emotional jobs (think about how fast brands and trends come and go).

It would be interesting to look at all the virtual products that have been sold by TenCent, Second Life, and ChangYou and divide the revenue and margins into functional and emotional job buckets (i.e. how much revenue has been generated by functional jobs vs. emotional jobs). 

I suspect that the opportunity for solutions to functional jobs is much higher than that for emotional jobs. 

Why an Idea is Worth Nothing

This is the beginning of a presentation I give to my class at Presidio. I gave it to Darius Sankey's class at the UCSD Business School last semester, and the students seemed to enjoy it. 

The title is provocative, but it is meant to inspire deep thinking about the innovation problem, especially for entrepreneurs. The data and the math are irrefutable: the chances of entrepreneurial success are close to zero. 

So the point is to think differently - really differently - about everything that goes into innovation. The goal is to fix the extremely high new venture failure rate.

An Idea Is Worth Nothing

View more presentations from jayhaynes.

The Elevator Pitch

A colleague of mine just sent me this HBS Elevator Pitch Generator. It is a nice tool, although I generally don't like elevator pitches. And I definitely don't think an elevator pitch should be focused on "explaining yourself, your business, your goals and your passions." Your "passions"? Who cares about your passions? As an entrepreneur you should be passionate about one thing only: meeting customer needs.

If you do an elevator pitch, it should be focused on your background, the customer need, the opportunity and your solution. There is only one goal: to make money. That should be obvious. 

Here's my one minute elevator pitch on why you should not do elevator pitches:

90% of all new products fail.

Only 11% of all venture investments get to liquidity.

Only 4% of all venture investments generate 62% of all the returns.

Almost half of all third rounds are flat or down.

Thus: innovation is fundamentally broken.

So spend an hour and listen to a detailed pitch solving the innovation problem.

And then spend an entire day thinking deeply about why innovation fails. Be honest with yourself and define every term rigorously.

Top 12 Product Management Mistakes

I was introduced to Martin Cagan, the head of the Silicon Valley Product Group. Martin has an impressive track record and is an expert in product management. And he seems like a really nice guy. I was told his article "The Top 12 Product Management Mistakes - And How To Avoid Them" is a legend in the valley. And his collection of writings is impressive. I am making my way through them all. 

I thought I would post some comments about each of the 12 mistakes that Marty has identified and add solutions based on ODI. The ODI method, language, and quantitative tools are very helpful in addressing each of these problems. My analysis of the first two mistakes is below (the others will follow soon). 

First, a quick review of some definitions we use. A customer need is a job that the customer is trying to get done, i.e. the task or goal the customer is trying to accomplish (for example, develop code, restore blood flow, communicate while mobile, etc.). Every job has between 50-150 outcomes, or metrics, that relate to performing the job with speed, stability and predictability (these include time, likelihood, frequency, amount, risk, and number). The job executor is the customer who actually performs the job. 

The value chain includes all the payers who help make, distribute, or service the solution, and each of these players have their own set of jobs to accomplish that are separate from the job executor. Purchase decisions are sometimes made by the job executor and sometimes by people in an organization who have different jobs to accomplish than the job executor. Jobs can be separated into functional jobs, emotional jobs, and consumption chain jobs. Functional jobs are the actual tasks that need to be performed. Emotional jobs can be personal (jobs that make you feel better about yourself) or social (jobs that make other people perceive you as a better person). Consumption chain jobs include purchase, receive, install, set-up, learn-to-use, interface, etc. Consumption chain jobs are separate from the functional job because no customer buys a product to install it or interface with it - they buy the product to get the functional job done. 

So let's review the 12 product management mistakes and add some ODI solutions.

1. Confusing customer requirements with product requirements.

Marty identifies three problems with letting marketing or sales or the customer define the product to be built. Let's look at each in detail.

First, he states that "customers don't necessarily know what they want." Marty is correct in the sense that customers don't know what solution they want. But they certainly do know what job it is that they are trying to get done. For example, customers didn't know they wanted a microwave, but they certainly knew they wanted to prepared food quicker. This is why innovation has to focus on the job the customer is trying to get done, not on the the solution (the product or service). If the job is the unit of analysis, the value of a solution can be quantified and predicted with much greater accuracy without having to build it. 

This is also why we believe there is no such thing as a "latent need." When people use the term "latent need", they are usually referring to the solution, not the need. In other words, customers didn't know they needed a microwave, so they must have had a latent need for a microwave. But there are no latent needs because customers always know perfectly well what job they are trying to get done. The certainly knew they had to prepare food quicker (a need) and the microwave (a solution) addressed that need well. 

Second, Marty states that "customers don't know what's possible." What he means is that customers don't know what solutions are possible. This is definitely true and I agree completely. Creating a solution is the role of the company, not the customer. Customers should not be asked what solutions they want - they should be asked what job they are trying to accomplish, regardless of the current solution they may be using or they may think they want. Product requirements should be generated by domain and technical experts only after all the customer needs (the jobs and outcomes) are known and all the needs have been quantified as under-served, over-served, or appropriately served. 

Third, Marty writes that "customers aren't in a position to see the wide range of needs and opportunities" and that they don't "have the time to learn about others in the market and how their needs may be similar or different." This is true, but there is a solution. The needs are the same for all job executors because the job is universal - it has process steps (a map) and 50 to 150 outcomes. In other words, in a market all the customers (the job executors) are trying to execute the same job. So their needs are the same. What is essential is knowing which of these needs (the 50 to 150 outcomes) is satisfied and how large (in dollars) is the opportunity. 

Product managers should begin the product development process with an innovation step. Innovation entails identifying the customer needs, quantifying the needs, calculating the addressable and securable market opportunities, generating a solution (platform, business model, and feature set), and validating the solution with a statistically significant customer sample.

2. Confusing innovation with value. 

Marty writes, "Innovation without a clear purpose is simply technology looking for a problem to solve." We use a different definition of innovation than Marty, and what he seems to be saying here is that "technology R&D without knowing the customer needs is simply an idea looking for a need to fill." And I agree with this. It is why we define innovation without any reference to technology. Innovation is creating and validating a solution concept (regardless of the technology to implement it) that satisfies customer needs. 

 

In ODI, a "problem to solve" is defined as a customer need (the job and its outcomes). This definition aligns the interests of everyone in the company: the board, the executives, the product manager, the engineers, the marketers, the sales team, etc. It solves the confusion problem by "providing a clear vision and product strategy," in Marty's terms, or in ODI terms: by providing a complete map of all the customer needs and a way to quantify the opportunities and validate the solutions before any development. 

Marty also states that "innovation needs to be in support of providing true customer value." Which is, of course, true. So what is true customer value? We define value from the customer's perspective: enabling the customer to get the job done better. This is the goal of innovation. And it is accomplished by increasing the satisfaction levels of the 50-150 outcomes that customers use to measure the success of getting the job done with speed, efficiency, and predictability. And because each outcome is a metric, each is knowable, measurable, and actionable. So true customer value can be calculated as a percentage between 0 and 100%.