Best Practice Area New Product Development Product Management

Why Do Products Fail?

Why Do Products Fail?
By Scott Sehlhorst
President at Tyner Blain LLC
Reposted with permission from
photo of a chessboard, showing a king on its side after checkmate

Why do products fail? Trying to organize all of the reasons that your product might fail is a Herculean effort. Understanding how your product did, will, or might fail will help you focus on what you need to do next.

An Exploration of Product Management

A personal goal for me is to become better at product management, so that I can help create better products.

As a product manager, the most important thing you should be doing is understanding the problems that your customers face. If you treat “improving at product management” as the product, you should start with an exploration of the problem space. I’m framing that problem space as products that fail. I think it is also fair to also think about products that under-perform. They “succeed” given the goals by which they are being measured, but they never realize their full potential. I’ll keep the “not as good as it could be” notion in the back of my head, and talk to “failed” as the larger issue.

There are conversations, blogs, books, processes, and frameworks for “how to be a (good) product manager.” I suspect looking at this from the outside-in (problem first, solution second) may yield some interesting insights. Thanks to Leisa Reichelt for her article on why most UX is bad, which inspired me to have the conversation here, approaching the problem as a root cause analysis.

As an agile product manager, I’m going to approach this iteratively. I hope that you will provide insights and corrections, helping to adapt this as we go. Your contributions will make this better, faster.

Root Cause Analysis of Failed Products

Ishikawa diagrams were originally created to allow engineers to figure out why something broke – a visual tool for organizing root cause analyses. I’ve been using this powerful decomposition tool for several years to solve problems and organize my thoughts. It may provide the perfect framework for gaining understanding about why products fail.

Let’s dive right in. Here’s my first crack at the very top level of an Ishikawa for product failure.

[larger version]

Looks pretty sparse (for now). I will fill it in, as I drill down into each area.

If you’re like me, you’ve got some “reasons for failure” in your head right now – maybe from past experience, maybe from watching products in the market today. Do any of those reasons not map into the categories above? Tell us about it in the comments (or tell me privately, if you must) – that’s the first vector for informing an improved version of this diagram.

Here are some prose descriptions of what I’m thinking about (for now) for each of those branches on the diagram – I expect them to fill out with smaller branches attached to each of the main branches.

Product Fails in the Market

  • Business Case is Flawed – This is where we would capture things like a product strategy that is not profitable, for example, your model was dependent on exponential growth – so even though you had consistently growing market share, it wasn’t enough for the product to be considered “a success” by you.
  • Picked the Wrong Market – Maybe this market is about to go away, like buggy whips or audio cassettes. Maybe the competitors in this market are just too good. Maybe entering this market is too divergent from your corporate strategy and dilutes focus and investment in your company’s other products. Another example would be if your team does not have the skills and resources needed to win in a particular market.
  • Takes Too Long to Enter Market – Whatever it is you’re doing to enter the market, it took you too long. Competitors have “out-gunned” you, your customer’s needs have changed, etc. This is to capture causes where even if everything else was good, you simply didn’t move quickly enough. At first blush, I expect organizational problems (lack of alignment, bureaucracy, insufficient resources) will all land here.
  • Doesn’t Solve the Right Problems – This is where most product managers focus most of their time – making sure we’re actually solving the right problems (the ones customers are willing to pay to solve). Problems of design – where we intended to solve the right problem, but the proposed solution doesn’t cut it – would not be in this branch – they would be in the “not good enough” branch.
  • Positioning & Sales Approach is Wrong – For the first iteration, this is my catch-all for marketing and sales. All of the problems that are “your potential customers don’t think of your product as a solution to their problems (even though it is).” Also the problems of “your potential customers decided not to purchase (when they should have)” and “your potential customers have never heard of your product.” This is definitely an area where you can contribute more than I can to the framework. How would you (product marketing managers, I’m looking at you) frame this?
  • Product is Not Good Enough – Execution is key here. Not solving problems completely (although that might move to the “right problems” branch) is an example. Bad design is an example – both bad user-experience and bad architecture. Poor execution also lands here – broken windows, sloppy implementations, poor quality. For this branch to work, “product” is not just the product that your development team builds, but also your customer relationships, distribution, services, etc.

Open Questions in This Model

There are definitely some design decisions I made in the approach above that are worth questioning. Here are some that come to mind for me – add your own in the comments.

  • Designs that fail to solve the target problems – I put this in the the “not good enough” bucket, because I felt like there was value in grouping the “how” separate from the “why.” Many times, an inadequate design is a design that works great for inadequate requirements – which means the problem is in the “why” column. How would you organize “bad requirements execution” and “bad design execution” in this model?
  • Pricing and Cost – together, they reflect profitability. ”Not profitable” implies a business case problem. Incorrect pricing implies a positioning problem or is a red herring that is masking a sales problem. High cost is reflective of bad design decisions and/or execution problems (both of which are in the “not good enough”) bucket. Perhaps if you can’t create the product at the cost you need to, for your business model to work, when selling at a given price in order to compete, you have picked the wrong market. Where would you put pricing and cost issues?
  • Team Capabilities and Support. Not having (enough of) the right skills on a team limits what solutions you can create. Not having enough support to gain needed skills constrains the solution space as well. When your team does not have what it takes, or have what they need, to create solutions that will succeed in a given market, where would you put this? For now, it is in the “picked the wrong market” bucket, because trying to compete in that market is infeasible. There’s probably a better way to frame this – how would you do it?

A Litmus Test

One experiment to validate this model is to look at the main causes of project failure and see if they map well into this space. In the Chaos Report findings from the Standish Group, the following are the top ten responses from the companies they surveyed, along with my thoughts about how they map into this framework.

  1. Lack of User Input – In my experience, this manifests both as not solving the right problems and as delivering a product that is not good enough. The mechanisms are different flavors of “not listening.”
  2. Incomplete Requirements & Specifications – Ends up causing delays, and possibly not solving the right problems, or having designs that are not good enough (because the requirements that drove the designs were not good enough).
  3. Changing Requirements & Specifications – I put this squarely in the “your mindset is broken” bucket. Requirements change, even if your requirements document does not. Depending on how this plays out (for your team, for your process), you either slog on and deliver solutions to the wrong problems, or you take too long to deliver.
  4. Lack of Executive Support – This can be a takes too long problem. Or it could be that lack of support causes a product to be abandoned (even if it were succeeding), or constrains options for your team to the point that you aren’t able to succeed within the parameters. This one definitely doesn’t fit the model. Should we update the model, or treat this one as “out of scope?”
  5. Technology Incompetence – insufficient skill results in not good enough and usually delivery takes too long. If really bad, it results in “impossible (for this team) to deliver.” For the really bad cases, does it land in picked the wrong market, because that market is infeasible?
  6. Lack of Resources – Just a subset of lack of executive support.
  7. Unrealistic Expectations – in the worst cases, it is a problem with the business model.
  8. Unclear Objectives – lands in not solving the right problem.
  9. Unrealistic Time Frames – same as unrealistic expectations.
  10. New Technology – yes, change is hard.

Not surprisingly, the list from the Chaos report uses a project-centric language. Other than the (very valid) “failure profile” that lack of executive support causes projects to fail, the model seems to hold up reasonably well.

Your turn – what would you add or change?

About The Author
Scott Sehlhorst, President at Tyner Blain, has been helping companies achieve Software Product Success for more a dozen years. Scott consults as a product manager, business architect, and business analyst. He has also worked as a technical consultant, developer, project manager and program manager. LinkedIn

Join the newsletter

Subscribe to get our latest content by email.
We won't send you spam. Unsubscribe at any time. Powered by ConvertKit