In the first and second parts of this series, I argued that people who write about product management and product marketing should be circumspect in their choice of topics. A field that's as young as PM in the tech industry isn't fertile ground yet for a grand theory of what the profession is all about. Categorizing the PM function was a good first step; now, we're in the middle of building "middle-range theories" about PM. A good set of field-tested guidelines for researching requirements, doing market opportunity assessments, or crafting the right marketing mix would be pretty darn good, thank you very much.

Aristotle beats down Plato in no-holds-barred epistemological cage match
In fact, middle range theories are an essential precondition of a grand theory. Big, unifying ideas, such as special and general relativity, don't come before the observation of the real world. (Sorry, Plato: the people who spend a lot of time in caves get prison pallor, not "actionable insights.") They always come after, when a set of hypotheses that seemed to work pretty well, until you noticed that the planet Mercury wasn't in the right place, made hash of them. Then, someone fretted over the inadequacies of these tenets, and after a fair amount of head-scratching and hair-pulling, came up with the big unifying idea.

But what makes the idea unifying? It's not that Newton's famous equation, f = ma, is what every scientist or engineer then used to solve every problem. That particular equation has only limited applicability, at best. The vast majority of post-Newton calculations used derivations of f = ma, in conjunction with other important equations.

All of this math depended on a set of assumptions about the physical world—some very obvious, such as Newton's three laws of motion, and some less obvious, such as his dependence on fixed frames of reference to make all the math work. If you like the equations, you have to embrace the concepts on which they were built. (At least, until a better theory comes along, with a different set of assumptions, such as no fixed frames of reference.)

My book about PM won't have the same table of contents as your book
What does this have to do with PM? Everything, when you're looking for guidance, such as the one book that describes what PM is all about. That book does not exist, and it cannot exist until we've made more progress in the study and practice of PM.

At this point, you might think that I'm dissing books like Steven Haine's The Product Manager's Desk Reference, which takes an encyclopedic look at tasks that PMs perform, such as product roadmaps, pricing, and portfolio management. Not at all: Haines' book is a great reference, but it does not provide an unassailable definition of product management. If it did, we wouldn't have any disagreements over whether some topic covered in his book (being an internal champion of your product, comparing its financial performance to the development investment, etc.) is the proper concern of a PM. We also wouldn't be having quite so many debates over topics like, In an Agile team,  should the PM also be the product owner?

One of the signature traits of PM is its diversity across technology companies, or even among different teams in the same company. Of course, no job looks exactly the same from one company to another, but as we've seen PM job descriptions vary a lot. Not surprisingly, the ultimate cause is uncertainty about the core of what PM is all about. (Since I summoned up the specters of ancient Greek philosophers, I'll throw out one of their favorite words, arete, that does a good job of capturing what we're missing.)

Until we've arrived at something more than a gut feeling, one person's excellent PM book will describe a different set of tasks and deliverables than another book. And, not surprisingly, books that focus exclusively on what great PM looks like will seem superficial, since they don't have a lot to talk about yet.

Books like Rich Mironov's The Art Of Product Management still serve an important role in describing the experience of PM for anyone who hasn't done it before. I like Rich's book a lot, for the same reason that I like the C.S. Forester's Horatio Hornblower novels: they explain to readers what it's like to serve in a particular role. However, after reading a couple of Hornblower books, I wouldn't try commanding a ship of the line at the battle of Trafalgar. Rich's book performs a valuable service, telling you if PM is right for you, and if you're doing it, and throwing out some good tricks of the trade that might be useful to you. (Again, some topics may not apply to your company's definition of PM.)

You may ask yourself, well, how did I get here?
We don't have to wait for the Einstein of PM to tell us what we should be doing. Please, get back to work, doing whatever you think PM should be doing. Our gut feelings about the essentials of PM are still pretty good guides to what should be on our to-do lists. People built the cathedrals of Europe, the Great Wall of China, and the pyramids of Mesoamerica and Egypt long before Newton was born. We need more of the middle-range theories (a.k.a. practical advice) that will help PMs achieve equally amazing things. Eventually, we'll have enough of these principles to step back, look at our experiences developing and applying them, and have a meaningful conversation about what it all means.

It would help move that conversation along if we had a conveniently-timed crisis of confidence in our earlier assumptions. Happily, that crisis already happening. Several industry trends have already challenged the basic assumptions behind what tech industry companies do, and what role PM plays in them. For example, removing many of the obstacles between software development and its actual use, SaaS often shows how little we understand about technology adoption. The speed of Agile iterations has undermined our concept of what a product release means. Opening the social media door to thousands of loquacious customers has led many companies to reconsider their basic business: Are we developing technology and delivering it to our customers, or creating value in collaboration with the customers?

PMs live on the boundary between business and technology, which is exactly where these agonizing reappraisals are happening. No one will have to wait for the "What the heck have we been thinking?" moments for very long.