Posted by Tom Grant on December 16, 2009
[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 Heretech.]