Why Do Products Fail? – Picking the Wrong User Goals

Continuing the series on root causes of product failure, this article looks at the impact of focusing on the wrong user goals. Even if you have picked the right users, you may have picked the wrong goals – creating a product your customers don’t really need, or solving problems that your customers don’t care about solving.

Why Do Products Fail?

This series is following a root-cause-analysis approach to understanding reasons that a product will fail in the market. A slightly different approach of “remembering the future” is being used. Imagine that your product fails in the market, and that you’ve been tasked with figuring out why it failed. You start by categorizing the reasons it may have failed, then start drilling down into the reasons behind the reasons. That analysis will lead you down many paths. To follow the series from the top level to this point, if you haven’t been reading along already, please review the following articles:

Where that article explored the Does not target the right users branch, this article explores the Does not focus on the important goals of target user personas branch.

Important Goals

Assuming you’ve already identified the right users (a focus on satisfying the preconceptions of the right buyers would lie in a different branch), you need to then have an understanding of what is important to them. Failing to focus on the important goals will happen if you (1) fail to identify the user’s goals, or (2) fail to appreciate the relative importance of each goal the user has. Failing to identify the goals is obvious – if you don’t discover the goal, you won’t solve it (except accidentally – you could get lucky). The other aspect of failing to identify important goals is not recognizing which of the identified goals are actually important to solve, for your target users to realize value.

As a side note – solving (important) problems in the wrong order, solving too few problems, and providing insufficient (partial) solutions to problems are all captured in other branches of the Ishikawa – this branch is solely about failing to identify important user goals and failing to appreciate the importance of those identified goals.

The first step comes in understanding your users.

Elicitation

You don’t want your users to define your product – you want them to inspire it.

The goal of elicitation is not to be told what to build, but to develop an understanding of why something needs to be built. The last question you want to ask is “what do you want?” You need to start by trying to get users (or potential users) to tell you about the problems that they care about solving. In my experience (excluding other product managers and business analysts), when you ask someone to articulate the problems that they face, they will unerringly tell you about problem manifestations instead.

If you ask a user to tell you what is wrong with an eCommerce site, he will tell you that the search is too slow, or that the results are not relevant. Those are problem manifestations. The problem the user is facing is that he cannot find what he is looking for.

When I’m describing the process of product management, I use the following diagram:

Asking questions is a form of market research, and the answers are data. You can’t jump directly from those answers to a roadmap or backlog – you have to analyze the answers to generate insights. In the case if elicitation, you’re developing insights about what the underlying problems are. It is the analysis and synthesis that leads you to discovering the underlying problems.

Prioritization

At the end of the day, you want to prioritize what you build in terms of maximizing your bang-for-the-buck. This has proven to be such a valuable framework that the Innovation Games folks have even created an online game out of the bang-for-the-buck technique. Given your available resources, it lets you maximize the rate at which you deliver value per unit of time (in the article, the focus is on prioritization within and across sprints, but conceptually it applies regardless of your development cadence).

Assuming you’ve picked the right users, and identified the problems that they care about solving, the key is to solve them in the right order. You may find you’re in a unique circumstance, but start with the point of view that “most valuable to the user” is the measure by which you should assign importance to the user. It is also imperative that you are thinking in terms of differentiated value relative to alternatives. Some abstractly-valuable problems already have solutions that are readily available to your users. Use the point of view that not-yet-solved problems are where the value is.

One framework for understanding the importance of (solutions to) problems is Kano Analysis – which you can use to identify if users view solutions to problems as more-is-better, delighting, or must-have.

There are actually several games from Luke Hohmann and the InnovationGames people that can help with this – here are a few:

20/20 Vision – get customers to put solutions to the problems into relative order (for them). Effectively, a card-sorting exercise.

Speedboat – the relative priority insight you get from this game comes when people put anchors at different depths, indicating the severity of a particular problem.

Whole Product – this brainstorming game can also be used to identify what people perceive to be Must Be (table-stakes) capabilities of your product.

Once you identify the importance of solving particular problems to your target customers, you have half the information you need to sequence what you will build (you also need cost estimates for creating solutions to those problems, to use bang-for-the-buck).

When you’re doing an analysis of the importance of problems, you’re usually looking at multiple groups of users. In the Important Problems article in the series on comparing products, you can see a method for visualizing the importance of multiple problems, to multiple users:

Summary

Even with an understanding of who the right users are, you still have to understand which problems are important to them to solve, and in which order you should solve those problems. That order should map to maximizing the value you can provide them in the minimum amount of time – achieving bang-for-the-buck, where your users define the bang, and you control the bucks.

Product Management Today

@sehlhorst on Twitter

Who Should Read Tyner Blain?

These articles are written primarily for product managers. Everyone trying to create great products can find something of use to them here. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!