Why Products fail

Most companies still use the same process to create products. Usually, everything starts with ideas. In most companies, they’re coming from inside, executives, key stakeholders or business owners, or from outside, current or prospective customers.

Then, most companies want to prioritise those ideas into a roadmap, to be able to work on the most important things first and to be able to predict when things will be ready. To accomplish this, companies form a business case for each item to figure out how much money or/and value vill it makes, and how much money or/and time will it cost.

At this point, the product and technology organisation has its marching orders, and they work the ideas from the highest priority on down. Once an approach makes it to the top of the list, the first thing that is done is to come up with a set of requirements. Their purpose is to communicate with the designers and engineers whats needs to be built.

Once the requirements are gathered up, the user experience design team is asked to provide the visual and interaction design of the product. And, finally, the requirements and design specs make it to engineers. And this is usually where Agile finally enters the picture.

You might recognise the process that I describe as a Waterfall process, although almost everyone today claims to be Agile. Yet, these same companies consistently complain about the lack of innovation and the time it takes to make from idea to customers’ hand.

Okay, so this may be what most teams and organisations do, but why is this necessarily the reason for so many product problems? In the list that follows, I’m going to present ten issues that are very common in the way of working of these organisations and are responsible for most failed product efforts.

This model leads to sales-driven and stakeholder-driven products. The ideas should come from the discover of if the customer will buy or choose the product, will be able to use it, if the team can build it and if the solution work for the business.

Another consequence of this approach is the lack of team empowerment. In this model, they’re just there to implement.

The way most companies do business cases to come up with a prioritized roadmap is very unreal. We can’t know how much money we’ll make because that depends entirely on how good the solutions turn out to be. And the truth is that many product ideas end up making nothing.

In any case, one of the most critical lessons in the product is knowing what we can’t say, and we just can’t understand at this stage how much money we’ll make. Likewise, we have no idea what will cost to build the product. Without knowing the real solution, it is tough to predict.

But companies want those prioritized roadmaps, and to get one, they need some kind of system to rate the ideas. So usually people play the business case game.

Many roadmaps are essentially prioritized lists of features and projects. But there are two inconvenient truths about products. The first truth is that at least half of our ideas are just not going to work. There are many reasons for an approach not to work out. The most common is that customers just aren’t as excited about the idea as we are, or the product is too complicated that it’s simply more trouble than it’s worth. And customers choose not to use it. So, at least half the ideas on a roadmap are not going to deliver what you hope.

If that’s not bad enough, the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several interactions to get the implementation of the concept to the point where it delivers the necessary business value.

There is simply no escaping from these inconvenient truths, no matter how smart we might be. The real difference is how we deal with these truths.

In this model, we can’t say that exists a product manager, but a form of project management because it’s more focus on gathering requirements and documenting them for engineers that focus on managing the product. So, there is a necessity of a 180-degree turn to what is the reality of modern tech product management.

The UX designers enter way too late in the game to get the real value of design, and mostly what’s been done is what we call the “lipstick on the pig” model. The damage has already been done, and now we’re just trying to put a coat of paint on the mess. And the Design team know this is not good, but they make their best effort to make it look as beautiful and consistent as they can.

If you’re just using your engineers to code, you’re only getting about half of their value. The little secret in a product is that engineers are typically the best single source of innovation, yet, they are never invited to the party in this process.

Teams using Agile in this way are getting maybe 20% of the actual value and potential of Agile methods. What we’re seeing is Agile for delivery, but the rest of the organisation and context is anything but Agile.

The company usually funds, staffs, pushes and launches projects through the organisation. Unfortunately, projects are output and product is an outcome. This process leads to something that although can be released, doesn’t meet its objectives, so what was the point? We need to think in a different way to build products.

The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed. The irony is that many teams believe they’re applying Lean principles, yet, they follow this basic process, one of the most expensive, slower ways we know.

We can’t get the time or money back that we lose while we’re busy doing this process. It’s no surprise that so many companies spend so much time and money and get so little in return. Companies must have a deep understanding of exactly why they need to change how they work.