CultureDevelopmentEnterprise SoftwareInnovationProcessProduct ManagementResearchSaeed

Prioritizing Features does not equal Product Management

I came across this blog post today: How to Outsource Product Management to Customers.

With a title like that, I had to read it. The post starts out well:

Product management is one of the most critical functions for any enterprise software company.

Hard to disagree with that! 🙂

But then the author writes:

As a product gets used by more and more customers, requests for new features start to pile up, and the job of a product manager is to prioritize them in order to meet customers’ needs, while avoiding feature creep.

Somehow that doesn’t jive with the first line, particularly if you end up “outsourcing Product Management.” Yes, prioritizing requirements is an important part of a the role of Product Management, but managing customer feature requests is only one small segment of the work Product Management performs.

The post on “outsourcing product management” is about an open source software company, Intalio, and how they fund development of key features in their product.

Their process works something like this:

  • Identify which features should be developed by having customers discuss and vote on a public list of candidate features
  • Estimate the efforts to develop the top rated features as ranked by the community of customers.
  • Solicit bids from customers for the development of the feature
  • Close the bidding process and start the actual implementation once enough customers commit to paying for it
  • Once a feature is complete, decide how the functionality will be made available to customers

While this process does work for Intalio, it is not really “outsourcing Product Management”, because, and perhaps it needs to be said explicitly:

Wikipedia defines Product Management this way.

Product management is an organizational function within a company dealing with the planning or marketing of a product or products at all stages of the product lifecycle

The emphasis on “at all stages” is mine, but it is key when thinking about the function of Product Management.

Product Management, particularly in technology companies, must be seen as a business optimization function across the product lifecycle, and NOT simply as a technical role in the planning of products.

Let me paraphrase myself from a recent post if I may:

If all a PM does is collect and prioritize requirements, then their job title may as well be “Requirements Boy” or “Requirements Girl”.

That is not the description of a strategic role. Although unfortunately there is no single, widely implemented definition of Product Management, the folks at Pragmatic Marketing have done a great job at succinctly defining areas of focus and roles for the Product Management function. Their famous “grid”

pragmatic marketing grid

(click to enlarge)

shows a very broad range of activities under three different roles. Now, I don’t necessarily agree with exactly how this grid is laid out, but that is a minor issue. Notice that “feature prioritization” is not even explicitly listed in any of the boxes!

Two of the boxes in the middle column: Market Requirements and Product Roadmap, come closest to the feature prioritization bucket. But also notice that the one box is “Market Requirements” and not “Customer Requirements”.

Customer requirements are a subset of overall Market Requirements, and thus anyone or any company that views the single focus of Product Management as collecting and prioritizing requirements doesn’t understand the need and value of Product Management. It’s like saying that the role of Marketing is to create brochures, or the role of sales is to meet with prospects.

So, I hope I’m not simply preaching to the converted here, but this past week, I’ve come across two separate blog postings (1, 2) about Product Management at Open Source companies, and in both cases, the incumbents at the companies — developers at mySQL and the founder of Intalio — pigeonholed Product Management into the “requirements prioritization” bucket.

Any ideas on how to change this misconception? And soon?