Video: The Root Causes of Product Failure by Marty Cagan "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 9 September 2015 True Marty Cagan, Mind The Product San Francisco 2015, Video, Mind the Product Mind the Product Ltd 1010 Marty Cagan at Mind the Product San Francisco Product Management 4.04
· 5 minute read

Video: The Root Causes of Product Failure by Marty Cagan

Let’s be honest, most products fail. Even in the best companies this happens – for every Google AdWords there’s a Google Wave. In this insightful talk at Mind the Product San Francisco, the inimitable Marty Cagan outlines what he sees as the root causes of these failures.

Most teams today start with an idea, even where we’ve adopted something like the Lean Canvas we simply reverse engineer the idea into it. The ideas come from internal “stakeholders” or customers. The next goal is to come up with a roadmap for the quarter or the year. There are many flavours of roadmap but it boils down to a prioritised list of those ideas, and in order to do that most companies develop some sort of business case for each idea. From the roadmap we assign teams and start gathering and documenting requirements, doing the design work and then putting it in front of the developers. At this point we’re Agile, sprinting through the requirements, testing and then deploying.

Well guess what? This is still Waterfall. And ultimately this is incredibly ineffective and ultimately why so many products fail. Why?

1. The source of the ideas. While asking internal stakeholders and big customers for ideas isn’t bad, they aren’t the best source of ideas. The best source of ideas is actually your engineers – they are the only ones who can help understand what the technology can do to solve customer problems. Another important source of ideas is of course data – and the people traditionally coming up with the ideas don’t have access to the data.

2. The business case fallacy. These have two basic inputs – how much money it’s going to make and how much it’s going to cost. But you have no idea about either of these. You can make it up – and we’ve all played this game – but you can’t know.

In technology products the most important thing is knowing what you can’t know.
-Marc Andreesen

3. Product Roadmaps. Roadmaps are the number one reason on Marty’s list of why products fail. They come from a reasonable request – management wants to know that the team is working on the most valuable ideas and they want some predicability in the business. The first inconvenient truth about product is that at least half of the ideas on your roadmap aren’t going to work. The second inconvenient truth is that even the half of your ideas that will work will take at least 3-4 iterations before they do. And if you look at the process outlined above you quickly realise that each of these iterations just takes too long.

Be stubborn on your vision, but flexible on the details.
– Jeff Bezos

Roadmaps are the details, not the vision. And it would be fine if roadmaps were just a list of priorities, but in most companies anything committed to a roadmap is a commitment to the business. And this is why roadmaps are such a problem. We become locked in to delivering these ideas even though we know most of them won’t pan out. And the problem is compounded in a larger organisation where different stakeholders fight for their piece of the roadmap and it just ends up being a big negotiated mess.

4. The role of product. Although product management is evolving, and some product teams are far ahead of their organisations, the job is most often still described as requirement gathering. But that’s not the job. The process above requires a project manager, this is not the role of product.

5. The role of design. In the process outlined above we’re not doing design – we’re putting lipstick on a pig. The design process only starts after a number of bad decisions have already been made.

6. The role of engineering. If you’re just using your developers to code – you’re only getting half the value from them. In the process above developers are coming to the process way too late, meaning they don’t have the full context, are treated as mercenaries just there to output code and you’re not getting the benefit of their creativity on the problem you’re trying to solve.

7. The role of Agile. While most of us will say we’re in agile teams, it’s really only agile in the delivery phase. The rest of the process outlined above is pure Waterfall, and this means the benefits of Agile isn’t felt anywhere else.

8. Output not outcome. This is a project centric process, which makes sense because it comes from a project centric world where it took years to develop software and you couldn’t iterate once it was shipped. But this means the whole process is focused on output instead of outcomes. If you instead focus on outcomes it might take multiple iterative releases to achieve that outcome, instead of one failed release that delivers an orphaned product with no impact for the business or the customer.

9. Customer validation comes too late. We’ve just outlined a process that takes a lot of time and money to build a new feature. But you only validate the feature with the customer at the end of the process, meaning it’s basically the most expensive way to validate ideas.

10. Opportunity cost. Although building software has become cheaper the teams to build them have only become more expensive, so we need to focus on doing more with less. And in the process above there’s so much profligate waste that the easiest way to do more with less is simply to stop a process that doesn’t deliver over half the time.

The best teams don’t work anything like this. The best teams embrace continuous discovery and delivery.

They set a clear vision based on customer problems. They involve design, product and engineering in generating ideas and then validate hundreds of them using MVPs and rapid iterations, and then deliver just the ideas that work – the ideas that are proven to move the needle.

Watch the video to get a taste of how Marty defines this and implements this in the teams he works with.

Comments 4

This is because you are a bigot.

Like a lot of stereotypes, there is some truth in this one. I have met developers who don’t want to deal with anything other than the code and are content to let someone else make decisions for them and to be told what to do. But this attitude is just classic bigotry: take some attribute that is true for some individuals in a group, and apply it to all those in a group.

There are many, many, many software developers who are well-rounded human beings and who have far more to contribute than just coding, people such as myself and my colleagues who have also been casualties of the bigoted culture you promote.

It’s this very same bigoted culture that cost my former employer 12 employees leaving and 2 1/2 years of inability to deliver a software project that should have taken 1 year tops, only to wind up scrambling to do in the final hour what I wanted to do in the first place. Who needs to listen to ideas from those code monkeys, though?

Join the community

Sign up for free to share your thoughts

About the author