Any PM who has worked with customers extensively learns how to deal with the hard cases. There are different species of difficult customers, such those who exaggerate every problem to the level of a showstopper, or the ones who think there's only answer to every implementation question.

As anyone who has worked on component technologies can tell you, the time in which you should treat your product as something that can stand on its own is limited. The tricky part is figuring out when that transition should occur—and that's where people in product marketing and product management can really earn their paychecks.

[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.

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.