Marty Cagan

In the mid 1980s, I was a young software developer working for HP on a high-profile product. It was when Artificial Intelligence was all the rage, and I was fortunate enough to be working at one of the industry’s best companies, as part of a very strong software engineering team (several members of that team went on to substantial success in companies across the industry). Our assignment was a difficult one: to deliver software on a low-cost, general-purpose workstation that until then required a special-purpose hardware/software combination that cost over $100,000 per user—a price few could afford.

We worked long and hard for well over a year, sacrificing countless nights and weekends. Along the way, we added several patents to HP’s portfolio. We developed the software to meet HP’s exacting quality standards. We internationalized the product and localized it for several languages. We trained the sales force. We previewed our technology with the press and received excellent reviews. We were ready. We released. We celebrated the release.

Just one problem: No one bought it.

The product was a complete failure in the marketplace. Yes, it was technically impressive, and the reviewers loved it, but it wasn’t something people wanted or needed.

The team was of course frustrated with this outcome. But soon we began to ask some important questions: Who decides what products we should actually build? How do they decide? How do they know that what we build will be useful?

Our young team learned something very profound—something I’m sure many teams have discovered the hard way: It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.

More generally, we learned that it’s not enough to do a good job engineering a product. At least as important is discovering a product that is valuable, usable, and feasible.

When trying to track down the root cause of our failure, I learned that the decisions about what to build came from a “Product Manager”—someone who generally resided in the marketing organization and who was responsible for defining the products we built. But I also learned that Product Management wasn’t something HP was particularly good at. I later learned that most companies weren’t good at this, and in fact most still aren’t.

I promised myself that never again would I work so hard on a product unless I knew the product would be something that users and customers wanted.

Over the next 20 years, I had the very good fortune to work on some of the most successful high-tech products of our time—first at HP during the rise of personal computers, then at Netscape Communications/AOL during the rise of the Internet where I served as vice-president of platform and tools, and finally at eBay during the rise of e-commerce where I served as the senior vice-president of product management and design.

Not all of the product efforts have been as successful as others, but I am happy to say that none were failures, and several became loved and used by millions of people around the world.

Soon after I left eBay, I started getting calls from product organizations wanting to improve how they produced products. As I began working with these companies, I discovered that there was a tremendous difference between how the best companies produced products, and how most companies produced them. I realized that the state of the art was very different from the state of the practice.

Most companies were still using old and inefficient ways to define and create products. I also discovered that there was precious little help available, either from academia, including the best business school programs, or from industry organizations, which seemed hopelessly stuck in the failed models of the past—just like the one I worked in at HP.

I have had some great rides, and I am especially thankful that I have had the chance to work for and with some of the best product minds in the industry. The best ideas in this book are from these people. You will find a list of many of them in the acknowledgements. I have learned from them all and I am grateful to each one of them.

I chose this career because I wanted to work on products that customers love; products that inspire and provide real value. I find that most product leaders also want to create inspiring and successful products. Yet most products are not inspiring, and life is too short for bad products.

My hope in writing this book is that it will help share the best practices of the most successful product companies, and that the result will be more products that are truly inspiring—products that customers love.

Who This Book Is For
This book is specifically written for those members of software product teams—especially Internet software product teams—both consumer and business, who are responsible for defining the products to be built. Often these product leaders are called “product managers,” but they may be company founders, executives, lead engineers, or designers.

In addition to product managers, this book is for user experience designers, software engineers and architects, project/program managers, product marketing managers, and the managers of the different parts of the product organization.

In my experience, the information described here is applicable to a wide variety of product development teams:

It doesn't matter how good your engineering team is if they are not given something worthwhile to build.

We need teams of missionaries, not teams of mercenaries.

To be absolutely clear, the product manager is not the boss of anyone on the product team.

Just as you need to know the language of computing, you also need to know the language of business. If you have never done so, you need to take a course in the basics of business finance.

Rather than being measured on the output of their design work, the product designer is measured on the success of the product.

Modern product marketing managers represent the market to the product team—the positioning, the messaging, and a winning go‐to‐market plan. They are deeply engaged with the sales channel and know their capabilities, limitations, and current competitive issues.

These are called outcome‐based roadmaps.

Outcome‐based roadmaps are essentially equivalent to using a business objective–based system such as the OKR system. It's the format that's different more than the content.

ome companies do formal business cases, and some are informal, but either way it boils down to the need to know two things about each idea: (1) How much money or value will it make? and (2) How much money or time will it cost? This information is then used to come up with the roadmap, usually for the next quarter, but sometimes as much as a year out.