Why Do Products Fail? – Picking the Wrong User Goals

This content is syndicated from Tyner Blain by Scott Sehlhorst. To view the original post in full, click here.

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:

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.


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:

[larger image]

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.


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:

[larger image]

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


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.

Post to Twitter Post to Facebook

Leave a Reply

Your email address will not be published. Required fields are marked *

ten + four =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”



To explore how we can help you, please get in touch