The 10 biggest problems that are causing your product efforts to fail

In the list that follows, I’m going to share what I consider to be the top 10 biggest problems with normal product efforts. Keep in mind that all 10 of these problems are very serious issues, any one of which could derail a team. But many companies have more than one or even all of these problems.

Photo credit: Rawpixel

The following is an edited excerpt from Inspired: How to Create Tech Products Customers Love by Marty Cagan. The excerpt is provided by Wiley Publishing. You can buy a copy here.

1. Source of ideas

The usual model leads to sales‐driven specials and stakeholder‐driven products. Lots more to come on this key topic, but for now, let me just say that this is not the source of our best product ideas. Another consequence of this approach is the lack of team empowerment. In the usual model, they’re just there to implement – they’re mercenaries. While almost everyone today claims to be agile, this is very much a waterfall process.

2. Business cases

Next, let’s talk about the​ fatal flaw in business cases. To be clear, I’m personally in favor of doing business cases, at least for ideas that need a larger investment. But the way most companies do them at this stage to come up with a prioritized roadmap is truly ridiculous. Here’s why: Remember those two key inputs to every business case? How much money you’ll make and how much it will cost?

Well, the cold, hard truth is that, at this stage, we have no clue about either of these. In fact, we can’t know. We can’t know how much money we’ll make because that depends entirely on how good the solution turns out to be. If the team does an excellent job, this could be wildly successful and literally change the course of the company. The truth, however, is that many product ideas end up making absolutely nothing. And that’s not an exaggeration for effect.

It’s literally nothing (we know this from A/B testing). In any case, one of the most critical lessons in product is knowing what we can’t know, and we just can’t know at this stage how much money we’ll make. Likewise, we have no idea what it will cost to build. Without knowing the actual solution, this is extremely hard for engineering to predict. Most experienced engineers will refuse to even give an estimate at this stage but some are pressured into the old T‐shirt-sizing compromise – just let us know if this is small, medium, large, or extra large. But companies really want those prioritized roadmaps, and to get one they need some kind of system to rate the ideas. So people play the business case game.

3. Excitement

An even bigger issue is what comes next, which is when companies get really excited about their product roadmaps. I’ve seen countless roadmaps over the years, and the vast majority of them are essentially prioritized lists of features and projects. Marketing needs this feature for a campaign. Sales needs this feature for a new customer. Someone wants a PayPal integration. You get the idea. But here’s the problem – maybe the biggest problem of all. It’s what I call the two inconvenient truths about product. There are many reasons for an idea to not work out. The most common is that customers just aren’t as excited about this idea as we are. So, they choose not to use it.

Sometimes they want to use it and they try it out, but the product is so complicated that it’s simply more trouble than it’s worth, so users again choose not to use it. Sometimes the issue is that customers would love it, but it turns out to be much more involved to build than we thought, and we decide we simply can’t afford the time and money required to deliver it. So, I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. (By the way, the really good teams assume that at least three quarters of the ideas won’t perform like they 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 iterations to get the implementation of this idea to the point where it delivers the necessary business value. We call that “time to money.” One of the most important things about product that I’ve learned is that there is simply no escaping these inconvenient truths, no matter how smart you might be. And I’ve had the good fortune to work with many truly exceptional product teams. The real difference is how you deal with these truths.

4. Role of product management

Next, let’s consider the role of product management in the model. In fact, we wouldn’t call this role product management – it’s really a form of project management. In the model, it’s more about gathering requirements and documenting them for engineers. At this point, let me just say that this is 180 degrees away from the reality of modern tech product management.

5. Role of design

It’s a similar story with the role of design. It’s way too late in the game to get the real value of design, and mostly what’s being 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. The UX designers know this is not good, but they try to make it look as nice and consistent as they can.

6. Engineers

Maybe the biggest missed​ opportunity in this model is the fact that engineering gets brought in way too late. We say if you’re just using your engineers to code, you’re only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation, yet they are not even invited to the party in this process.

7. Agile methods

Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late. Teams using Agile in this way are getting maybe 20 percent of the actual value and potential of Agile methods. What you’re really seeing is Agile for delivery, but the rest of the organization and context is anything but Agile.

8. Project-centric process

9. Customer validation

10. Time and money