June 08, 2009

"The Biggest Breakthrough in Innovation Ever"

Great article by Jack Martin Leith on Outcome-Driven Innovation.

May 13, 2009

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. 

4. Confusing the Customer with the User

Marty correctly identifies that "The person who buys the product to address a business requirement may have very different concerns from the people that sit down and use the product every day."  In ODI terms, this problem can be structured as different people in the value chain with different jobs to get done. The reason this is a better way to frame the problem is that each of the jobs for each of the different people can be known and quantified. In other words, a "business requirement" is a job to get done. 

In any value chain, there is a core functional job that needs to be accomplished. And that job has directly related jobs and indirectly related jobs. So the jobs of the purchase decision maker need to be analyzed as well as the jobs of the core job executor (who is performing the functional job). Only with a full understanding of all of these needs (all of the jobs and outcomes) can a company be sure that a customer will make a purchase and be satisfied with the solution. 

5. Confusing Features with Benefits

Marty writes, "Your product simply must have a crystal clear, simple and compelling value proposition." And "There are several possible reasons for poor value propositions. The most common is that the product is not solving a significant enough problem."

I would be surprise if any serious entrepreneur didn't know that their product had to have a compelling value proposition. VCs and entrepreneurs say this all the time. But what does it mean? What is a value proposition? The problem is not that entrepreneurs don't know they need to have a value proposition - it is defining what a value proposition is.

And from the customer's point of view, there is only one value proposition: helping them get a job done better. The only reason a customer will buy your product is if it helps them get an important and unsatisfied job done better. 

The good news is that using the job and its outcomes (the 50-150 metrics) as the unit of analysis, entrepreneurs don't have to guess if they have a "compelling" value proposition. They can measure the value their solution creates for customers. A "compelling value proposition" is an almost useless term. But satisfying an outcome is value that can be calculated between 0-100%. In other words, using the job and outcomes to analyze value is much, much more accurate because this is how customers think: does your solution help me get the job done better.

And a feature has only one purpose: to satisfy an outcome. And that satisfaction level can be validated with customers. This is why outcomes are so powerful. Unlike other customer requirements that are vague and variable (e.g. "easy-to-use", "reliable", "convenient"), outcomes are measurable (minimize the time it takes to..., minimize the likelihood of..., increase the amount of...). So with outcomes, value add is knowable and measurable. 

More to come...

May 11, 2009

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.

May 07, 2009

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.


May 06, 2009

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. 

May 04, 2009

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. 

May 01, 2009

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.

April 30, 2009

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


April 29, 2009

"Heavy" Startups

I was with a good friend and great entrepreneur this weekend who has recently become a venture investor. He is exceptionally talented and I have a great deal of respect for him. He said something that made me think about startups and the innovation process. I was walking him through the details of our innovation methodology and he said, "that's heavy."


What he meant was that our process might be too detailed for a nimble startup financed with seed capital. But let's look at what any startup will confront, regardless of the model used to innovate. 

Of course, every startup has to ship a product or service that meets customer needs. That's a given no matter what the market. But a startup also exists within a value chain of suppliers, distributors, competitors, OEMs, etc. What this means is that the product or service not only has to meet the needs of the customer (the job executor) but also of the other players in the market who either help create the product or help distribute it. And each one of these players has needs that need to be met as well (i.e. they have jobs to get done). 

If every job has 50-150 outcomes, and every job executor has multiple jobs to get done, and every value chain has multiple players, the number of outcomes that need to be known and quantified upfront is certainly "heavy".  

A startup doesn't get to avoid these metrics simply because the cost of development has decreased. It can choose a "fail fast" strategy with lower levels of funding to try to satisfy needs. But this doesn't mean the needs are less "heavy", it just means that the startup is lighter. 

And there is more evidence today that the light and fast version does not work any better than traditional methods.