Why Do Products Fail – Solving the Wrong Problems

There are many reasons that a product might fail in the market.  One of those reasons is that your product solves the wrong problems.  There are many ways to solve the wrong problems.  This article continues the series on sources of product failure, exploring the idea that your product may be trying to solve the wrong problems.

Quick Recap of Product Failure

In an earlier article on why products fail, I framed the problem as a root-cause analysis, using an Ishikawa diagram to categorize the sources of product failure (in the market).

[larger version]

There’s a great discussion in the comments on the first article – focused mostly on “picked the wrong market” and interpretations of positioning.  The initial article frames the reasons for product failure as being discoverable by exploring one or more of the following branches of the Ishikawa:

  • Business Case is Flawed
  • Picked the Wrong Market
  • Takes Too Long to Enter Market
  • Doesn’t Solve the Right Problems – the focus of this article
  • Positioning & Sales Approach is Wrong
  • Product is Not Good Enough

In this article, the focus is on solving the right problems.

[larger version]

Solving the Right Problems

How do you know if your product is solving the right problems?  There are two questions – did you pick the right problems to try to solve, and did you succeed in solving those problems?  The focus of this article is entirely on the selection of the right problems, not on how effective your solution is at solving them.  The “Product is not good enough” branch would capture scenarios where you picked the right problem, but then your solution failed to deliver a valuable solution.

[larger image]

Broadly classified, there are 6 reasons that your product may not be solving the right problems.  All of these branches represent a failure to make the right decisions based on external factors – being market driven, or outside-in in your perspective about what needs to be done.

  • Doesn’t enable user personas to realize value – the focus of this article
  • Doesn’t address buyer persona’s perception of problems
  • Doesn’t align with (customer) company’s strategy for competing in their market
  • Is not differentiated from alternative solutions
  • Did not solve the problems in the right order
  • Did not solve enough problems – or solve the problems enough

Enabling User Personas to Realize Value

One aspect of being market-driven is being user-centric.  To do that, you have to identify who your user personas are, and what they care about.  Users have goals, and user personas are archetypes designed to help you create products for groups of users that share common goals.

When you’re developing consumer products, creating user personas is sufficient for describing groups of users.  When you’re creating B2B products, you’re trying to address the needs of people that operate within an organization – and often there is a lot of complexity within that organization.  You can organize your insights into which people within your customer (company) perform which roles using actor hierarchies – a common tool for mapping use cases to particular roles.

For example, a call center manager will make sure calls don’t wait in the queue for too long, while a call center employee will make sure that each call is handled efficiently.  However, not all call center employees are the same either.  Often there are multiple roles, or tiers, of call center employees – designed to reflect levels of expertise.  Since most calls are straightforward, newer or less experienced employees are often tasked with handling the incoming calls, and then redirecting them to more experienced or specialized experts only when needed.  This allows a company to more efficiently utilize the time of the (more expensive) experts.  All of these employees will share some goals and tasks, but the more specialized employees will have additional tasks and goals.

You may also use hierarchies to reflect variations in roles – see this article on using actor hierarchies to address regional differences in a global business.

It isn’t sufficient to identify who your users are, you have to also identify what they care about.  The combination of “for whom” and “why they care” sums it up.  In an earlier series on comparing products, my point of view builds around the idea that your framework for comparison – if you want to be honest – should come from your customers.  That approach and series has a lot of overlap with this article.  After identifying the personas for your product, the next step was identifying the problems that are important to them to solve.

From that series – a view of the problems that Tim, a niche-content consumer, cares about when considering a mobile content consumption device:

[larger image]

If you don’t understand that Tim is your customer, and you don’t understand what Tim cares about, the only way that your product will satisfy Tim’s goals is through a happy accident.  If you aren’t being intentional, then definitely explore this branch as a reason why your product may have failed.

Summary

Just setting the framework for figuring out if you’re solving the wrong problems for the wrong users took a little more writing than I expected.  The next article in this series will continue exploring understanding if you’ve got the right customers in mind.

In the first article of this series, you gave some fantastic insights and poked at the framework very effectively.  Does anything jump out at you as missing, errant, or broken with this branch of the root-cause analysis?  Chime in below!

24 thoughts on “Why Do Products Fail – Solving the Wrong Problems

  1. Pingback: Roger L. Cauvin
  2. Pingback: Roger L. Cauvin
  3. Pingback: bishoph
  4. Pingback: Geoffrey Anderson
  5. Pingback: The Dude
  6. Pingback: TXTNLRN Dan
  7. Pingback: Mark Stephan
  8. Pingback: Vasily M. Komarov
  9. Pingback: Alan Kleber
  10. Pingback: 3.0
  11. Pingback: Alltop Agile
  12. Pingback: Kaerynne Nakamura
  13. Pingback: Marino Fadda
  14. Pingback: Jennifer Bubriski
  15. Pingback: SolutionsIQ
  16. Pingback: Simo Salminen
  17. Pingback: Geoff
  18. Pingback: VasilyKomarov RSS
  19. Pingback: Wade Armstrong
  20. Pingback: Matt Badgley
  21. Pingback: Sven Peters

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>