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.
[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.
- 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.”
- 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).
- 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.
- 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?”
- 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?
- Lack of Resources – Just a subset of lack of executive support.
- Unrealistic Expectations – in the worst cases, it is a problem with the business model.
- Unclear Objectives – lands in not solving the right problem.
- Unrealistic Time Frames – same as unrealistic expectations.
- 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?
Scott, my first comment: I am wondering if you could split the causes up into Internal and External. It appears that you may have already done this with the top level categories seemingly external and the bottom internal.
Second, and I am not sure if it is covered or if it could be grouped into an existing case, but the situation of business prioritization. An example of this would be a sales driven business mentality vs. market driven. I’ve seen several examples of development time and effort targeted at a select customer or narrow vertical market only to have that market dry up, go away, or not pan out. This symptom can occur at any level within the organization and result in a combination of “takes too long” and “doesn’t solve the right problems”.
How will these combinational issues be grouped since failure is rarely from a single point?
Great start and good information. Thanks for sharing.
Hey Larry, thanks for chiming in!
On internal-versus-external, I didn’t slice it that way – and here’s my rationale – tell me if it works for you.
In 2006, I wrote about team member perspective being a key aspect for each person determining “internal vs. external” classification of problems in Requirements Documents – One Man’s Trash. That mindset led me to a – from the company’s perspective – everything is internal. If the market is “bad”, that’s external, sure, but the decision to enter a bad market is internal.
I love the “build for a single customer first” behavior as an example for this – I’ve seen it many times also – in the B2B / enterprise space.
I think you’re right that it lands in a mixture of “takes too long” and “wrong problems.” I think the approach I’m using is tricky, because most of our inputs are descriptions of problem manifestations that are complex. I think very few of the problems will lend themselves well to “single solutions.”
As we flesh out the rest of the model, either it will make more sense (I’m hoping) or it will become less cohesive and we’ll need a new framework.
Scott,
Insightful and methodical – but I would expect nothing less. :-)
I’m weighing in from Product Marketing about the Positioning and Sales component. I started our thinking I would talk about indicators or symptoms of bad positioning but there are a number of issues in this bucket that could be at work. Unfortunately, the symptoms are the same: no leads, no conversion, no pipeline, no sales engagement/activity, no wins, etc. The cause may not always easy to diagnose.
I think of positioning as who you sell it to, where and against whom.
Messaging problems are where you may be positioned correctly but what you are saying has no meaning or value to those listening.
Sales process issues is where there’s a disconnect between how your team sells and how customers want to buy: channel, medium, trials, billing, etc.
I’ve had to do this more than once and fixing things involved lost sales analysis that included all constituents: Sales, Sales Management, Support, Partners, Analysts – and Customers.
Tim you raise some good point regarding the marketing aspects. I think these would fall mainly in the “Positioning & Sales Approach is Wrong” line. However, one thing that leads up to this is the metrics that are used to gauge this before it becomes a death nail.
Marketing ROI is tricky. The problem is how to measure an outcome that can be influenced by a variety of outside factors (e.g. competition, economy, feature set, exposure, quality, etc.) Still, the metrics can be the sign posts making marketing is less of an art and more of a repeatable process.
Hey Tim, thanks for the great comment!
The way you define “positioning” makes me want to classify positioning problems as “wrong market.” Then I would update the branch to be “Messaging and Sales Approach is Wrong” to capture the bad strategy and bad execution problems in both.
Do you think that works better?
Also – thanks for calling out “channel” – also got that call-out in email from a reader.
Also a great callout that the symptoms are the same – definitely the crux of this. In engineering, that’s why we used the Ishikawa for RCA (root-cause analysis). It helps bring clarity of finding the underlying problems (plural) that cause particular symptoms (measurements) to reveal themselves. I suspect this exploration may help us identify some more “surgical” metrics that provide us with insight about specific problems.
Yes, it works better to have positioning be a “Wrong Market” component.
An example on where channel can be an issue – If you are introducing a new product, your existing channel may not be the right one, even though the product is in the same sector. Channel readiness goes well beyond someone attending training. We introduced a cloud version of our product, with a different billing/licensing model, and most of our existing partners didn’t have compensation plans in place for the sales people to get paid appropriately. They got full comp on selling an appliance but got paid monthly (an annuity) for the cloud service. Some partners changed their comp plan to accommodate and things got better from there.
Tj
Thanks again, Tim.
I started to try and move positioning into the “wrong market” bucket, and ended up with this quandry:
From your “who you sell it to, where, and against whom”
Scott,
Overall positioning is a “what market are we in” decision and sometimes there a subtleties that are significant. Case in point at one previous employer was the product was marketed as a “web filtering” product where it was getting slammed by the incumbent. I moved it up to the “web security” market with the add on “yea, we do web filtering but that’s commodity and not that important, let’s talk about security which is important.” We did a lot better after that.
Once you are clear what market you are in, then the rest should fall into place like buyer persona, routes to market, competition, etc. I refer back to Geoffrey Moore’s seminal positioning guide from “Crossing the Chasm”:
For (target customer)
Who (statement of need or opportunity)
That (product or company name)
is a (product category or market segment)
That (statement of key benefit – compelling reason to buy)
Unlike (primary competitive product or alternative)
Our product (statement of primary differentiation)
Tj
Hey Tim,
This is a great example to use to poke at my framework :). If I understand what you’re saying, you changed the messaging / value-prop to one that is emphasizing “web security.” I agree that that is a change in positioning. Did you actually change markets – or did the new message resonate better with buyers (even if they are new buyers) in the same market?
I forgot to add…
So, I’m going to keep “positioning” with sales. I think “choosing the market” is part of it, and then saying “who is my buyer?” is a sub-ordinate decision, and one best mapped into sales.
I think there are very few intrinsically bad products.
Doesn’t Solve the Right Problems
===========================
Where most products fail is trying to solve a problem, that’s not worth solving. It doesn’t matter how excellent the engineering or marketing is if customers don’t need it.
Positioning & Sales Approach is Wrong
===============================
The next most common failure seems to be a great product that is not found by the right customers, the customers that need it. This could be due to a general lack of marketing, poor, unclear marketing but is typically down to poor targeting because they don’t know what type of customer needs this.
Hey Giles, thanks for chiming in!
There might be few “intrinsically bad” products, but I feel like there are fewer “intrinsically great” products. But it’s all about how you define “good.”
The K-car was a great product from Chrysler’s perspective – it reinvigorated the company in the face of eroding sales to imports. Personally, I find it to be a mediocre product (at best) from the customer’s perspective.
Cynically, the positioning could be “This car is (barely) good enough, and was made in America, by people like you so you should buy this, instead of something made by a foreigner who is not like you – at least if you want other Americans to have jobs.”
I suspect this “good v bad” thread is a better beer-conversation, since it could devolve in any number of interesting ways :)
Hi
What about market conditions that change rapidly – i.e. due to technology, competitive or other shifts. I’ve seen good products get commoditized in about 1 year because of technology changes, or emerging products get crushed because of competitive moves by larger companies.
Granted, you don’t have control over these but they are reasons why products fail.
Saeed
Hey Saeed,
Thanks – yes, absolutely!
I’d start out by saying that those market conditions exist for all of the competitors, so your ability to compete in that market (relative to the other players) will be determined by internal factors.
When I created “takes too long to enter the market” – I was really intending to capture when your team is not capable of “keeping up” with the chosen market. That could be because you shouldn’t have selected that market (given team-capability as a “fixed”), or that now that you’re in that market, you better improve your team.
If you’re Facebook, you “can’t” abandon the social-network-based-advertising market – if you start losing, you need to improve your team.
If you’re a start-up, you may be able move to a different market faster than you can upgrade your team.
I think there’s a feedback loop that has to happen, that the Ishikawa doesn’t show well, to let you know that the “inability to deliver quickly” is really a “wrong market” problem for one team, and a “takes too long” problem for another team.
On the “crushed by larger companies” point – I’m definitely taking it from an empowerment perspective – you got crushed not because the big company stepped on you, but because you failed to see it coming and move out of the way.
To empower your team, put the “can we avoid getting crushed, or do we need a different market?” question on the table.
Oh yeah, and one other reason should be added for failing — too stupid to succeed. :-) I’ve seen a lot of companies in this category.
BTW, what might be a good addition to this is a list of companies categorized by the reasons they failed. e.g. Cuil fit multiple categories.
Great idea – I definitely think we could take market problems and map them into this framework. I suspect each example will hit multiple spots too. Could be fun, definitely would be a learning exercise.
As to the other point – I like the way people like Fred Wilson put it – you invest in the team, not the idea.
Great article. Product Managers: You and your teams will fail if you are hunkered down in your bunker…
Thanks Mark!
I think there are really two parts to this question — design and manufacturing. You can have a great product design but if you can’t build it in sufficient volume with high quality, you’ll fail. Gillette is a great example of a company that combines product design and manufacturing groups in a single facility (in Boston). Apple also does a good job at designing products that can be manufactured in volume. Cost also ties into this. Beautifully designed products are at times expensive to manufacture.
Software doesn’t have the ‘manufacturing’ problem however, one could argue that the installation and configuration issues faced by the buyer are really a manufacturing-like problem. If a download a software trial and it is difficult to install and configure, I’m done!
Hey Vin, thanks and welcome to Tyner Blain!
Your comment reminded me of a job interview I had once, when I was hired to start a design department (when I was still an engineer) on-site at the manufacturing location. The director told me (paraphrased) “The guys at the design center create these great designs, but we just can’t build them. We need to come up with designs for our products that we can actually manufacture.”
My internal monologue (and I may have said it out loud too!) was “If you can’t build it, by what definition is it a great design?”
I did (and still do) contend that an infeasible design is not a great one, any more than one you can build but can’t sell. A great product has to solve all of the problems.
As a former mechanical engineer, I actually do think that software has the ‘manufacturing problem’ – it just manifests a little bit differently. Instead of building 40,000 units a day (which is what we did with one of my products when I was designing electro-mechanical controls), you create one unit that can be used by many people concurrently. The scaling challenges come in the operations side of things, instead of the creating of the product.
You could also argue that there are “manufacturing” challenges in coordinating teams and systems for large projects that are analogous to assembly issues in physical goods manufacturing. Different components (to be assembled) have to define tolerances and parameters that allow them to work together effectively within a physical product. Different architectural sub-systems in software need to have parameters of inter-operation defined as well. When you have a team working on the user interface, and one working on the business logic, and one working on the data-store, they all have to work together. Add in the “manufacturing processes” of automated testing and builds, and you have to adapt your code to enable those processes – just as you have to adapt your (physical product) design to the constraints of manufacturing.
I love the analogy – and it has inspired me to take a new approach at “design for automated testing” with a team with which I have worked in the past. Thanks again!