Against a grand theory of PM, part 1

When you're start working in an unexplored field of study, such as PM in the technology industry, it's tempting to propose the Grand Theory Of Everything (GTOE). It's also the worst possible time to develop a GTOE.

Opinion is cheap
Two years ago, when I started this job, I knew I'd have a full research agenda. Very few people took on the job of pundit, arguing for a particular vision of how the PM function should work. Even fewer had any hard data on how it actually does work, in practice. Before making any sweeping statements about the profession, I needed to fill in some big empirical holes.

How diverse is the PM job description, across companies? Which sort of requirements do PM teams give priority? Does moving from an on-premise to a SaaS model have an effect on the PM role? Moving at an Agile pace must have some effect on the rest of the company—but what is it? Without answering these questions, it's next to impossible to give advice.

For example, some aspect of technology companies has made the PM job description different across teams. Unless you understand the forces that have conspired against a consistent job description, there's little point in telling PMs what they should and should not be doing. It's almost as useless as your doctor telling you, "If you're not feeling well, just get better."

Research is hard
Nevertheless, as you're doing the research, you can make important observations specific to the topic that you're currently investigating. Sometimes, the answers are obvious. For example, when I was researching social media as a new source of customer and market intelligence, it was pretty obvious from the start that there was real work involved in using social media in this capacity.

Other times, it's harder to find the patterns. Sorting through the reasons why PMs in one Agile teams is the product owner, and in another team the PM and PO are two different people, took a lot of head-scratching.

You also discover that your initial hypothesis can be completely wrong. I had expected that the companies that invest in requirements tools would be bigger and older, and therefore relatively more capable of affording the purchase and implementation. Unfortunately, the opposite was the case: on average, it's the smaller, newer companies, who feel they can't afford not to invest in these tools, that lead adoption.

Important conclusions are still possible
Consequently, anyone trying to figure out how to make PM work in the tech industry is going to be working primarily on middle-range theory, not the GTOE. If middle-range theory doesn't sound important, it's worth remembering the significant role that this level of work has played in the hard sciences. Observations like, Gravity bends space-time, or, These hitherto unnoticed chemical sequences are the reason why you're a human and not an antelope, are major steps forward in our understanding of how the world works.

If someone can figure out why even the most meticulously written and reviewed requirements don't stop some tech companies from making products that their users don't like or can't understand, that's a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GTOE.

Next: The difference between theory and classification.

[Cross-posted at The Heretech.]