Why Do Products Fail? – Picking the Wrong Users

Exploring the reasons that a product might fail in the market is a useful way to triage and assess what you need to do to prevent the failure of your product. Instead of taking the “do these things” approach as a prescriptive recipe for product managers, I’m approaching the exact same topic from the opposite direction. I was inspired in part to explore this approach when thinking about the Remember the Future innovation game. Instead of asking “What will the system have done?” in order to gain insights what it could be built to do, I’m asking “Why did your product fail?” in order to prevent the most likely causes of failure.

Exploring Causes of Product Failure

In the first article on why products fail, I started with the top-down categorization of sources of product failure.

[larger version]

Within that framework, we started diving in to the causes of product failure that could be broadly described as “[the product] does not solve the right problems.”

[larger version]

Breaking this down involves exploring why the problems are not the “right” problems to solve.

[larger image]

One branch of the Ishikawa involves failing to solve the problems that are important to the user personas. That’s what we’ll explore in this article.

[larger image]

There are several ways in which you could reach the conclusion that user personas have failed to realize value.

[larger image]

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]

Focusing on the Right User Personas

Developing a set of user personas to guide the development of your product is important for several reasons. It provides a framework for focus – only building what is needed by the people who will actually use the product, not building what someone thinks “would be cool.” It provides a framework for prioritization – yes, some users will do that, but most won’t, so we’ll do that later. It provides context for the team to avoid a common manifestation of not having defined users – the elastic user problem. It gives you an opportunity to build a product that people love – creating loyal customers.

The first challenge is to make sure you identify the right users. The approach I describe here may only make sense in the context of the customer-centric market model that I use for thinking about markets – I’m not sure, it is so wired into my approach now that I may fail to clarify why I make some statements (if so, go read the earlier article). In a nutshell, this approach defines a market as follows:

Markets are made up of market segments, which represent groups of customers who share common problems that people will pay to solve. The notion of “customer” is combining both buyer personas and user personas to simplify the model.

Many products are relatively straightforward – within a given market segment, there is only one important user persona. For many B2B and enterprise software products, there are multiple user personas who collaborate to solve business problems. You need to understand the ecosystem of how your customer operates in order to identify the user personas that are important. Sometimes, the important user personas are not the people who directly interact with the system – they can be people who “use” the outputs of the system. In an article on visualizing stakeholder analysis, I show how to use an onion diagram.

stakeholder interactions

[larger image]

In a nutshell, there are direct users of the system, other employees (of your B2B customer) who are part of the containing system, and still other actively involved “users” in the wider environment. You identify these “non-user users” by understanding the interactions and goals of the [traditional] users. You could choose to focus only on the actual users, or identify the “other” users that make up part of the ecosystem. Both approaches work. The same user story would be syntactically different:

As the pest control company admin, I need to be able to quickly see the history of our relationship with a customer when she calls me, so that I can deliver personalized service, so that I can improve our customer’s satisfaction with our service.

As a pest control company customer, I want to know that my company cares about me, because I’m willing to pay a premium to support local merchants as long as I get personalized service.

I suspect it is a matter of personal (team) preference, but I prefer treating the non-user users as first class citizens. I believe you are more likely to generate insights about the problems the user-users should care about solving, when you start getting inside the heads of their customers – a key approach to developing B2B2C products.

Once you’ve identified the users, you need to identify the relative importance of each group of users. Choosing who to satisfy – or who to satisfy first is a manifestation of your go-to-market strategy. Selection of the “right” strategy is a little too broad of a topic to cover here, a thousand words into an article on user persona prioritization. As part of a series on comparing products, I made the case that you have to compare products from the perspective of users, and that the comparison should be weighted based on the relative importance of the users. In that article, I touch on market size, cross-market influences, higher-level strategy, risk mitigation, and ease of entry (into the market) as key areas of focus in strategy formulation.

The methodology for weighting the comparison in the context of user goals and the relative importance of users can also be used to prioritize investment decisions in your product.

Summary

As the detailed Ishikawa implies, there is more to come about failing to address the needs of your users. More to come in future articles. To summarize this installment,

  • Your product failed because you failed to solve the right problems.
  • You failed to solve the right problems because you did not enable the users to realize value.
  • You failed to enable users to realize value because you either (a) failed to identify your users, or (b) failed to prioritize solving problems for the right users.

To avoid product failures that stem from these root causes, identify your users, and their relative importance in the context of your particular strategy.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

49 thoughts on “Why Do Products Fail? – Picking the Wrong Users

  1. Pingback: Alltop Agile
  2. Pingback: Alan Kleber
  3. Pingback: Yama
  4. Pingback: Eric Herberholz
  5. Pingback: Joshua Duncan
  6. Pingback: Vineet Vashishta
  7. Pingback: Julie Hunt
  8. Pingback: Rich Mironov
  9. Pingback: Innovation Games
  10. Pingback: Kimmo Kontra
  11. Pingback: lukehohmann
  12. Pingback: Inspired-iQ Ltd
  13. Pingback: Eric D. Brown
  14. Pingback: Olaf Kowalik
  15. Pingback: Sam Palani
  16. Pingback: Bogdan Costea
  17. Pingback: Karl Jayasingha
  18. Pingback: Mark Stephan
  19. Pingback: Innubu
  20. Pingback: SolutionsIQ
  21. Pingback: Chetan Jain
  22. Pingback: Chetan Jain
  23. Pingback: Dorai Thodla
  24. Pingback: rajendra raja
  25. Pingback: Kent McDonald
  26. Great stuff Scott!

    This aligns with what you stated, but too often, companies with early stage products are unwilling to even select a target market and try to sell to anyone that looks like a potential fit. This happens because they never did the market validation work to understand which segment has what problem, as you describe here.

  27. Pingback: Colabpro
  28. Pingback: Tom Evans
  29. Pingback: Trevor Rotzien
  30. Pingback: Jeffrey Davidson
  31. Pingback: htmlapps
  32. Pingback: VasilyKomarov RSS
  33. Pingback: Chetan Jain
  34. Pingback: Andrej Ruckij
  35. Pingback: Vasily M. Komarov
  36. Pingback: Joan Benson
  37. Pingback: Sopheon
  38. Pingback: ProdMgmt Talk
  39. Pingback: Breanne Swim
  40. Pingback: ExecutiveBrief
  41. Pingback: Guillaume Iacino
  42. Pingback: Michael
  43. Pingback: Nashib Qadri
  44. Pingback: Jon Harmer
  45. Pingback: Matt Badgley
  46. Pingback: Matt Badgley

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.