Preface to the Second Edition
When I wrote the first edition, it was before Agile Product Development was well established in product companies, and before Customer Development and Lean Startup nomenclature became popularized. Today, most teams have been using these techniques for several years and are more interested in what’s beyond Lean and Agile, which is what I focus on here
PART I Lessons from Top Tech Companies
It doesn’t matter how good your engineering team is if they are not given something worthwhile to build
CHAPTER 1 Behind Every Great Product
A Product Team is comprised of at least a product manager and usually somewhere between 2 and 10 engineers. If you’re creating a user‐facing product, you would expect to have a product designer on your team as well.
CHAPTER 2 Technology‐Powered Products and Services
Technology‐powered products do not need to be purely digital
CHAPTER 3 Startups: Getting to Product/Market Fit
In the technology world, we generally have three stages of companies: startups, growth‐stage, and enterprise companies
I loosely define startup as a new product company that has yet to achieve product/market fit.
the very high failure rate of technology startups is no secret. The few that succeed are usually those that are really good at product discovery, which is a major topic of this book.
CHAPTER 4 Growth‐Stage Companies: Scaling to Success
the signs of organizational stress are everywhere. Product teams complain that they don’t understand the big picture—they don’t see how their work contributes to the larger goals, and they’re struggling with what it means to be an empowered, autonomous team.
you start to hear the term “technical debt” from every engineer you speak with.
CHAPTER 5 Enterprise Companies: Consistent Product Innovation
Strong tech‐product companies know they need to ensure consistent product innovation. This means constantly creating new value for their customers and for their business
Yet, many large, enterprise companies have already embarked on a slow death spiral.
tremendous number of stakeholders throughout the business working hard to protect what the company has created
Product teams complain about the lack of vision, lack of empowerment, the fact that it takes forever to get a decision made, and product work is turning into design by committee
Leadership is likely frustrated, too, with the lack of innovation from the product teams
CHAPTER 6 The Root Causes of Failed Product Efforts
(For earlier version of this chapter, see (2015-06-05) Cagan Product Fail.)
everything starts with ideas
most companies want to prioritize those ideas into a Roadmap, and they do this for two main reasons. First, they want us to work on the most important things first, and second, they want to be able to predict when things will be ready.
You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I’ve just described is very much a Waterfall process
In the list that follows, I’m going to share what I consider to be the top‐10 biggest problems with this way of working
Let’s start at the top—the source of ideas
Next, let’s talk about the fatal flaw in these business cases
the way most companies do them at this stage to come up with a prioritized Roadmap is truly ridiculous and 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
many product ideas end up making absolutely nothing
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
An even bigger issue is what comes next, which is when companies get really excited about their product Roadmaps.
But here’s the problem—maybe the biggest problem of all. It’s what I call the two inconvenient truths about product
The first truth is that at least half of our ideas are just not going to work
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
Next, let’s consider the role of product management in this model. In fact, we wouldn’t call this role product management—it’s really a form of project management.
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
Maybe the biggest missed opportunity in this model is the fact that engineering gets brought in way too late
Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late
This entire process is very Project‐centric. The company usually funds projects, staffs projects, pushes projects through the organization, and finally launches projects. Unfortunately, projects are output and product is all about outcome
The biggest flaw of the old waterfall process has always been, and remains, that all the risk is at the end, which means that customer validation happens way too late
Finally, while we’re busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead. We can’t get that time or money back
The good news is I promise you that the best teams operate nothing like what I’ve just described