Why Do Products Fail? – Incomplete Solutions

This article continues the series exploring the root causes of product failure. Even when you target the right users, and identify which of their problems are important to solve, you may still fail to solve the problems sufficiently.

Why Do Products Fail?

Imagine the one year anniversary of your product launch. The head of your business calls a meeting and asks, “So, why did the product fail?” Defensively, your boss explains that it wasn’t product management’s fault – you picked the right users, did the research, and identified the problems that they care the most to solve – and are willing to pay to solve. And that’s what went into the roadmap, and solutions to those problems are what the team built. At that moment, the nagging, amorphous thought that had been bugging you finally crystallizes and you chime in.

Maybe we didn’t solve the problems enough.

Enabling Users to Realize Value

This article builds on the framework below (from Why Do Products Fail? – Solving the Wrong Problems)

[larger image]

Specifically looking at the branch of root causes in the lower-left corner.

There are two different ways that a product may fail to sufficiently solve the problems that are important to your users.

• Does not address enough of the user’s needs – teams usually catch this when talking about “table stakes” for a product.
• Does not sufficiently address the needs that are addressed – this is the trickier one, knowing when something is “good enough.”

Unless you have a relationship with your customers built on trust – they trust that you will eventually “get there” – you will have a tough time convincing someone to buy a product that is “not ready for prime time.” [I hope that that is the last of the trite phrases describing minimally viable products, but we’ll see how it flows.] The difference between the two root-cause branches is that one is top-down (e.g. the sum of solutions is not enough), and the other is bottoms-up (e.g. individual solutions are inadequate).

The Minimum Viable Product (MVP)

It is always fun to talk about the latest shiny object in the product management lexicon. Talking about MVP is particularly fun because the concept is incredibly valuable, nuanced enough that many non-product (management | marketing) people don’t understand it, and MVP is at high risk of being misused. Most of the confusion that I’ve seen comes from placing the emphasis on the wrong word. Which is tough, since there are only three.

1. The Minimum Viable Product
2. The Minimum Viable Product

That’s it in a nutshell.

Most of the best practices of software development, in particular agile and lean* methodology, bias us towards focusing on – almost fixating on – the former. How quickly can we get the minimum product out the door? This isn’t a criticism of the “message of agile” – just an assessment of what happens to a lot of teams, as a result of hearing the message. I suspect, for some people, when you emphasize minimum, the message that is heard actually excludes the under-emphasized word.

When someone says “minimum viable product”, the audience hears “minimum [mumble] product.”

It makes sense that the emphasis has been on the word “minimum.” Agile’s David needed a potent sling against waterfall’s Goliath. Iterative development is built on the premise that you can discover, along the way, the best product – and that you can’t, in advance, (completely) determine what the right product will be. A major component of the value proposition of agile has been that by releasing earlier, you start getting revenue earlier. Get something valuable into the market now, start delivering value now, start realizing revenue now. As the product gets better, you’ll get more sales, and accelerate the timeline for realizing revenue.

This message resonates effectively with business leaders who are willing to “give it a try.” The problem comes in when those leaders forget that “go to market early” still has to be coupled with “finish the product.” The old mindset of “build until launch, then enter maintenance mode” is the problem. You can’t have your cake and eat it too – when you release early (and you should), you need to keep developing until the product is done (viable). Only then do you move into a maintenance mode.

When someone says “minimum viable product”, for some reason, the audience hears all three words. The reaction is “yeah, viable, but what, precisely, do you mean by viable?”

We’ll come back to that – it’s easier to describe the top down by referring to the equivalent concept from the bottoms up.

And that’s exactly the right question to ask.

*Eric Reis describes the MVP as the minimum required to get value (for you) – which could be simply learning about the market, a precursor to succeeding in the market. That’s actually a very good thing, and very useful – the only risk is that you forget that a particular release is an experiment designed for learning, and not a product designed for success. So – don’t stop experimenting, just make sure you don’t confuse the laboratory prototype with the market-viable product. Make sure you keep investing until you have a product that is both minimum and viable.

Solving the Problem Enough

In addition to solving enough of the problems that a user faces (to make the product viable), you have to solve those problems sufficiently. This is the bottoms up view. When describing how effective your product is at solving a problem, there are really only four possibilities.

1. Your product does not address the problem, and therefore does not solve it.
2. Your product inadequately addresses the problem, and therefore does not solve it.
3. Your product adequately addresses the problem, thereby solving it.
4. Your product does something to redefine the market, in such a way that the problem becomes irrelevant, thereby effectively solving it.

When it comes to knowing if you’ve solved a problem enough to satisfy your users, Kano analysis is the right framework to use. Specifically, you are focusing on the more is better problems.

[larger image]

For these problems, there is a range of possible solutions. The homepage takes too long to load. How fast does it need to be? I spend too much money on gasoline for my car. How much does fuel efficiency need to be improved to solve this problem for me?

One of the rules of writing requirements is to make the requirements verifiable (and by implication, measurable).

A structurally sound*, well written requirement may look like the following:

• Reduce the elapsed time to provide the estimated price for an average customer request from 7 minutes to 3 minutes or less.

*Assuming that “average customer request” and “elapsed time” are clarified to be unambiguous, and the user doing the providing is also identified.

The question that is the crux of this issue comes from understanding why the requirement-author picked 3 minutes. Would 4 minutes be inadequate? Does the goal really need to be 2 minutes?

Perhaps a business case for the product was defined, and moving from 7 minutes to 3 minutes is what is required for the project to comply with the cost-model built into the business case. Most of the teams I’ve seen would have said “3 minutes sounds good – it is a 57% improvement” and patted themselves on the back when they achieved it. The better teams would have referred to the business case, demonstrated the ROI of achieving the requirement versus the costs of the project, and patted themselves on the back when they achieved it.

Notice that neither of those approaches is based on an analysis of what the user considers to be acceptable.

The best teams would have taken into account user-adoption (or abandonment) rates when building the business case. Those teams would have immediately raised the question – “How good does it need to be to satisfy the users?” Then they would have put in the effort to figure out what the user needed.

The minimum viable capability for solving the problem in this example is to provide the estimated price in 2 minutes or less.

Solving Enough of the Problems

For each problem, you need to solve it enough – or you won’t get credit for solving it at all.

Just as people have a notion of “better, but not good enough” that they apply to the continuum of solutions to a particular problem, they have the same notion when applied to a set of problems.

When defining a product, you may identify a user who has five problems that you want to solve with your product. It may be that users are willing to consider any product that solves 3 of the 5 problems to be good enough – but not a product that only solves two of the problems.

The minimum viable product is one that solves 3 of the 5 problems.

See, much easier to get the idea across after looking at the single-capability view first.

Summary

Even after identifying the right users, and the right goals (problems), you have to solve enough of those problems, and you have to solve them well enough.