What Product Management Is Not

Posted by Marty Cagan on March 7, 2008

Tags: product management, product discovery

I find that many companies remain stuck in old, failed models of product management, and don’t always realize how important role definition is to building effective teams and successful products.

In several articles I’ve tried to explain what the role of the product manager is really all about, but in this article, I’d like to come at this from another angle and try to emphasize what the job is NOT. I’m hoping that calling out these misunderstandings will help companies realize where they have issues and hopefully revisit how they are defining this role.

- Product Management is not defining the business case

Some product managers believe their job is simply to define the business case for why this product should be built. Is the business case important?
Of course. Mainly because management will use this to make decisions on where to invest. But this doesn’t really do anything to contribute to actually creating the product. In many organizations the product manager does put the business case together, or at least contributes to creating the case, and this is fine, but don’t confuse this with the product management job.

- Product Management is not defining market requirements

For many companies, they think the product manager defines the market requirements and the engineers build a product to meet those market needs. The product manager creates an MRD (Market Requirements Document) that enumerates what the product manager thinks the market is looking for, and then actually defining the product that meets these requirements is an exercise left to the reader (which is typically an engineer). There are really two issues here.

The first is the fallacy of so-called “market requirements.” Markets don’t have requirements. People do. And the person that’s actually going to be defining this product has got to talk to these people directly. If the engineer is the one defining the product, then that person is the true product manager and you can only hope he understands that as the product manager he needs direct face-time with actual users and customers.

The second issue is the fallacy of market requirements separate from product requirements. The whole idea is to discover a product-market fit and this requires a deep understanding of both the market needs and the technology’s capabilities. It is during the discovery process that you identify true market requirements and technical solutions that successfully address these requirements.

- Product Management is not requirements gathering

Many companies, especially those with a direct sales organization, have the model where the job of the product manager is to gather up the requirements from the customers or prospective customers, document them for engineering, and then make sure those requirements are delivered by the dates the sales guys promised the customer.

This is not product management. This is project management for custom software solutions. True product companies know that customers have issues that need to be addressed, but they are not in a position to dictate the product requirements. In other words, you can’t make the mistake of confusing a customer requirement with a product requirement.

Be wary of anything that encourages this “requirements capture” or “requirements management” mentality. It is a very slippery slope and one of the surest paths to failed products.

- Product Management is not project management

In some companies, the product management group was borne out of the project/program management organization, especially when the company has an IT or custom software heritage. In this model, the product manager is considered the person to collect and document the requirements, and manage the project from conception to delivery. But the discovery process is not simply a task in a project plan. It is its own process, which is very different than the product development process. Moreover, rarely do you find individuals that like both product management (discovery) and project
management (delivery) as the nature of each type of person is so different.

- Product Management is not product marketing

Finally, product management is not about pricing, promotions, positioning and messaging, or product launch activities. Nor is it about online marketing and customer acquisition strategies or influencer marketing programs. These are all critically important activities, and the product manager will provide input to many of these activities, but don’t confuse them with product management. These are product marketing activities, and for all but the smallest products, you are going to need a skilled marketing person dedicated to this. While the company might be tempted to ask the product manager to cover these responsibilities as well, realize that the nature of these marketing-based activities is dramatically different than the discovery-based activities, and it’s very hard to find people that are skilled at both.

In contrast to the above, the product manager is responsible for discovering a product that is useful, usable and feasible. If he can do this, he’s done his job. If he can’t, there’s no point in spending the time and money to build and launch the product.

If your company makes any of the mistakes above, pass this note on to your management. Ask if perhaps you could try adjusting the role on your next product to see what happens. I think you’ll find that if you can focus on discovery, you’ll get a chance to show your company what product management is really all about.