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 jobs-to-be-done 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, and all of the needs in the job, 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 the needs. 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 needs in order to validate that the feature satisfies the functional job's needs. And because needs in the job 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 jobs-to-be-done 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 in the jobs 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 surprised 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 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 a need in a job is value that can be calculated between 0-100%. In other words, using the job and the needs 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 a need in the job. And that satisfaction level can be validated with customers. This is why jobs are so powerful. Unlike other customer requirements that are vague and variable (e.g. "easy-to-use", "reliable", "convenient"), needs in the job are measurable (minimize the time it takes to..., minimize the likelihood of..., ). So with jobs-to-be-done, value add is knowable and measurable. 

More to come...