Against a grand theory of PM, part 2

[You can find part 1 here.]

Most fields of study start with classification. The important precursor to any theory, middle-range or grand, is putting what you're studying into conceptual buckets that help organize the topic in meaningful ways. That's where the study of product management and product marketing started, and that's where it has stayed for the last several years. (For more discussion on that point, click here.)

Those conceptual buckets are important, for a variety of very practical reasons. For example, any theory of PM needs to exclude things that are not PM-related. As any of us who have been in the PM profession knows, defining the boundaries of PM has been difficult. The specialized consulting firms, such as Pragmatic Marketing and Sequent, have done a good business helping their clients sort out what their PMs should and shouldn't be doing.

It's a long stretch, however, from classification to grand theory. It took centuries for people studying the natural world to figure out that the classification of matter into four substances (earth, air, fire, and water) wasn't leading to any great insights into physics and chemistry.

On the other hand, when classification hits on something important, it can lead to important insights. The Victorian world's passion for sending researchers to distant lands, to add to the catalog of botany and zoology, led to Darwin contemplating the variation among finches in the Galapagos Islands, which led to the theory of evolution.

However, Darwin's short path from classification to theory is the exception, not the rule. In the PM world, it's important to recognize that someone needs to focus on requirements, and product managers, not product marketers, are the right people for that task. But how much work is necessary to do requirements well? What are the risks of doing a sub-par job with them?

And those are just the obvious questions. Here's a less obvious one: Is there a single correct template requirements? If so, PMs are just experimenting with different collections of content, until they collectively discover the equivalent of double-entry bookkeeping, the format on which all accountants standardized.

On the other hand, requirements might be a medium of thinking and communication that organizations use in whatever way makes sense to them, much as they treat e-mail. Some companies prefer to use e-mail sparsely, keeping more detailed discussions out of the message threads. Others like being chatty in e-mails, and expect their employees to contribute generously to these conversations. In the same fashion, some tech companies prefer detailed product plans to define the contents of the next release, while others create more minimalist documents, with other details to be found elsewhere (or not written down at all).

The answer to that question has profound consequences for the efficiency of development teams, the accuracy with which they guess what customers really want, and the larger organization's ability to bring new products and services to market. Peering into any periodic table of PM responsibilities, or roles, won't reveal the answer. That classification scheme, as useful as it may be, also does not how to measure PM's essential contribution to the company, which impediments put that contribution at risk, and how to resolve these issues.

[Next: So what kind of insights should we be trying hardest to achieve?]

[Cross-posted at The Forrester product management blog.]

Comments

[Saeed Khan]

Tom,

I liked where you started in part 1, but I have to say, I'm a bit lost with part 2. Maybe I should read it a couple of times and think about it a bit more.

The double-entry bookkeeping example is a bit of a red herring IMHO. Double entry was/is a way to reduce, errors in the book keeping process. No pun intended but it provides a way to check and balance (Is that the origin of that phrase?) the data that is entered.

Numbers in that context are very discrete and definitive. Those are 2 adjectives that cannot always be applied to requirements.

Sticking to the requirements issue, a well written, well defined, well explained etc. requirement may actually be a poor requirement in the context of the product and what the market needs. I could write the perfect requirement for a completely unnecessary capability.

i.e. there are dimensions of requirements that aren't always embedded in the literal body of the requirement.

Perhaps the definition of requirement needs to change to include it's value?

I'm just talking out loud here.

But back to the unification theory -- or lack of it -- I'm interested in seeing part 3, as that may help answer some of the questions I have.