Why Some Products Catch On Like Wildfire—and Others Don’t

During the course of the past 30 years, Marty Cagan has served as an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett-Packard, Netscape Communications, America Online, and eBay. He is the author of Inspired: How to Create Products Customers Love, in which he shares lessons learned, techniques, and best practices from working for and with some of the most successful companies in the high-tech industry. Cagan recently spoke with François Stragier, associate director in BCG’s Paris office and a core member of the Technology Advantage practice, to discuss design, usability, and what it takes to make great products.

Marty, your book is titled Inspired: How to Create Products Customers Love. In your view, what characterizes a good product?

A good product is one that solves a real problem for your user or customer, in a way that meets the needs of your business. Creating something your customers love is actually not too hard (if you use modern techniques). However, doing it in a way that works within your business model, technical constraints, staffing constraints, financial constraints, sales and marketing strategy, and legal and partnership constraints—that can be pretty tough.

You stress the importance of early, frequent, and high-fidelity prototyping for IT product development. Why is this so important?

The reason it takes many iterations is twofold. First, it’s just a reality that many of our ideas won’t actually work out—usually because our customers are not always as excited about our ideas as we are. Second, even with good ideas, it takes many iterations before something works well enough to actually solve the problem. In product companies, we often talk about “time to money” rather than “time to market.” Time to market is important but not helpful if the goals have not been met.

The reason we use so many prototypes, also known as minimum viable product experiments, is because it’s a tiny fraction of the cost to create and modify MVPs when compared to using expensive and highly skilled staff to design, build, test, and deploy an actual product.

Many corporations have large IT projects that go on for quarters—if not years—before any "real" users see the results and can test it. What are the consequences of this long development cycle?

The (very predictable) consequence of this approach is failure. These types of projects are referred to as “big bang” releases. They are almost never successful, and the reasons have been known for many years. Normally, we would not want to go longer than two weeks before we can actually test our ideas in front of real users and customers. So obviously, months or years would be unimaginable for a modern product team.

This does not mean that it takes just two weeks to build and deliver a full product. It means that we are testing out our high-risk areas early—value, usability, feasibility, business constraints—and adjusting before we invest significant funds. Then we are building and delivering incrementally.

In your book, you seem to suggest that software product development has become too important to be left to IT alone. How can companies bridge the gap between business and IT? Does this require a change in the skills of IT organizations and the management style?

In Silicon Valley, we have a very important and meaningful distinction between “IT” and “technology-powered product organizations.” You are describing what we would consider IT, not a product organization. An IT organization is there to serve “the business.” A product organization is there to serve the company’s customers, in ways that meet the needs of the business. The differences are many and profound.

I would argue that the underlying reason for so many failed efforts in large, legacy companies is because they do not understand this difference. They try to create products the same way they do their IT projects. However, to succeed with technology-powered products for actual customers, the company needs different skills, different staff, different development methods, different mindset, and often different culture and different leadership.