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:
- Why Do Products Fail? (Reasons a product fails in the market, including not solving the right problems)
- Why Do Products Fail? – Solving the Wrong Problems (Reasons a product does not solve the right problems, including not enabling users to realize value)
- Why Do Products Fail? – Picking the Wrong Users (Exploring one branch of the reasons that users do not realize value)
The specific reasons roll up to the following categories (read it as “The product…”) :
- Does not target the right users – you may have solved someone’s problems, but not the right someone.
- Does not focus on the important goals of target user personas – you may have picked the right users, but you failed to focus on the most important goals that they have.
- Insufficiently addresses the user persona’s needs – even with your eye on the ball – the right problems for the right people – you may not solve those problems “enough”.
- Does not account for user persona’s level of experience – as people use a product, the nature of the problems they face evolves – “ did you take that into account?
- Does not incorporate the context of usage – solving the right problems, sufficiently, for the right people is not enough – you have to account for the context in which they care.
When looking at the details under each of these categories, we get to the root causes of failing to enable your users to realize value from your product.
[larger image]
Why Do Products Fail? – Picking the Wrong Users
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.
Henry Ford’s apocryphal “faster horse” quote comes to mind of course – we’ll never be free of it (see Patrick Vlaskovits’ article on the HBR blog – a fascinating read regardless, including Alfred Sloan’s market segmentation approach – “A Car for Every Purse and Purpose“).
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.
Tom Chi describes it as framing the problem correctly.
Roger Cauvin gives us some great advice on interviewing prospects that warns us from making some common mistakes. The easiest way to get past problem manifestations and discover underlying problems is to ask “why?” and then ask it again. Roger also gives us advice on when to stop asking why – when you reach the core. You can visualize this with Ishikawa diagrams (much as this article series is attempting to do). Using this article series as a meta-example, picking the wrong user goals is a problem manifestation, product failure is the problem. Roger (again) provides some great insights in an analysis of an article by Karl Wiegers, where he provides some good real-world examples of identifying user-needs. Another handy trick for elicitation – ask provoking questions to stimulate lateral thinking. While we’re piling up the articles for deep-diving, here are some key active-listening techniques that you can use not only to assure that you understood what someone is saying, but to probe into the root-causes and discover 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:
The above table shows hypothetical data representing the “quantified” relative importance of having a solution for each problem, to each persona / context.
Important Problems – Comparing Products Part 4
[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.
37 thoughts on “Why Do Products Fail? – Picking the Wrong User Goals”