Quality: The Zen of Product Management

Quality is an issue that can never be far from a Product Manager's mind. Quality is a nebulous idea that is hard to define, let alone create. Yet a PM's approach to quality can be a key factor in the success or failure of a product.

Decades ago, a computer manual writer named Robert Pirsig wrote a book about quality. Zen and the Art of Motorcycle Maintenance is the most widely read philosophy book ever written (and also has the distinction of having been turned down by more publishers - 121 - than any other best-seller in history). It contains an important insight that helps explain why product managers need to cultivate multiple, seemingly contradictory perspectives regarding their products.

Using the example of maintaining a motorcycle, Pirsig explains how some people view the world through a "romantic" lens of experience - how something feels in the here-and-now. Someone with this attitude judges whether something works in a pleasing or effective way, not why. This motorcycle owner doesn't care about the intricacies of the machine's design, and may not be interested in maintaining or improving it - but may care very much that it runs well and looks good.

Pirsig contrasts this viewpoint with a strictly rational lens - evaluating something in terms of how it works, its design and technology, and why it does what it does. This motorcycle owner is cares about the workings of the engine, and takes pleasure in making sure that the machine is running well. This rational understanding of the product contributes to the user's appreciation of it.

The romantic attitude would lead a software or web user to judge a product based on factors like aesthetics, discoverability, and efficiency of use - without being cognizant of these as measurable "qualities". The rational approach would be typical of someone who likes to understand the product, customize it, and perhaps play a role in improving it.

The romantic viewpoint is common among the customers of software product and web services - they want these things to work well, be easy to learn, and be pleasing. It's an approach that's typical of the majority of users of business and consumer applications and service.

On the other hand, there are usually a smaller number of users who are strictly rational - often power users, system administrators, and early adopters, These may be important users, and they are sometimes very vocal, but they are often in the minority, often a very small minority.

The rational approach is often ubiquitous in an engineering/development organization. Techies tend to be relentlessly logical, almost by definition. It's this attitude that makes them good engineers or QA testers. They are good at viewing the quality of a product in terms of efficiency, functionality and technical elegance.

The challenge for the product manager is to understand both these points of view, and to fully appreciate that customers and engineers have very different ideas of what constitutes quality. Pirsig says that merging these two viewpoints is the key to understanding the world more clearly. In the world of product development, the incentive is more immediate: it can be a matter of success or failure.

The PM who focuses exclusively on the customer's experience can easily fall into the trap of making products that are easier to use, but are limited by the customer's vision. Breakthrough ideas are rarely articulated by customers - a PM needs to take an analytical approach to understand why a product satisfies (or doesn't satisfy) a customer, to understand the underlying problems, and make the conceptual leaps that result in breakthroughs. PMs must be logical and analytical.

On the other hand, a PM who is exclusively analytical is not likely to understand the feelings and emotions that a customer experiences when using a product. These are often the reasons that a customer will choose - or not choose - one product over another. A PM who is not tuned into the customer's inner experience is not likely to drive the creation of a product that is deeply satisfying to users.

The value of a multidimensional understanding of quality is especially important during development. A PM needs to be able to communicate the customer's feelings to a detail-oriented engineering team, and at the same time must understand the team's need to create solutions that are functional and efficient. Without this "bipolar" understanding, a PM can't play the dual role of customer advocate and development partner.

I've heard that it takes a certain kind of personality type to be a good product manager. I've always felt that it requires a special combination of empathy and rationality. Maybe you don't have to a zen master to be a good product manager. But cultivating a zenlike view of quality sure helps.

Popular posts from this blog

You Are Who You Hire (part 1)

Just Saying "No"

Passion