The Product Management/Marketing Job And Department Profiler is finally, finally available (Forrester account required). This project was unusual in  a lot of respects, so it's worth spending a little time explaining it. You might also get some insight into how research gets done at Forrester, which might be a little mysterious to the outside world.

What is it?
Here's the short version: You enter the priorities for a particular PM, and you get a recommended job description. If you want to go one step further, you can also get a picture of what your department should look like: how many PMs, in which specializations, at which level of seniority for their positions.

In other words, it's a tool designed primarily for the people who run PM groups. The Profiler is also useful for rank-and-file PMs who might want to gauge where their priorities and skills are, and where they should be.

I'll get into more details about the tool and how it works in a later post, but let me first explain why I created it.

What inspired it?
Last  year, I ran a survey to find out what PMs were doing in their jobs, versus what they thought they should be doing. The results, released in the document "Product Managers Were Working On The Wrong Things," were very interesting.

For example, we saw in stark terms how product managers struggled to stay focused on their core work, helping the development team make good products and services, because they were pulled into many tasks that were not directly relevant, such as marketing support and sales enablement. At the same time, product marketers had their own version of "the urgent defeats the important" principle, with too many conflicting priorities and too few resources to address all of them.

Of course, the next question is, "Now what?" The point of this study wasn 't merely to commiserate, but to suggest a course of action to fix what is perhaps the core problem with product management and product marketing in the technology industry: vagueness about roles, responsibilities, skills, and deliverables. Research that dramatized the problem was necessary, but not sufficient to do more than generate broad recommendations (for example, run your department so that product managers can focus on their requirements).

Why this approach?
After having defined a problem area, the standard analyst response is to dig more deeply into each part of it. And, to a large extent, that's what I've been doing. Natural topics for further research included:

  • How the development and delivery processes shaped the job description, which led to work on product management for SaaS products, and the role of the product manager in (or adjacent to) development teams that have adopted Agile methods. 
  • What PMs produce, which inspired some work on serious gaming and product requirements.
  • Where new opportunities to improve product management exist, such as the multi-part series on the role of "inbound" social media as a new source of requirements. Again, in this case, we circled back to the question of how the nature of the work—in this case, collecting information from social media channels—affects the definition of the job.

In fact, nearly everything that I've written points back, to some extent, to the roles and responsibilities of product managers and product marketers. Are they really two different roles, or one? If they're separate, should they be part of the same department, or different ones? What are the important adjustments in a PM's to-do list, based on the type of product they're working? How do these changes dictate the skills necessary to handle these tasks? What kind of authority should PMs have, over which kinds of product-related decisions?

Rough sketch, not paint by numbers
Even if I did the best job imaginable in each research document, I still felt that something was missing. Tech companies want baselines against which to measure their own PM organizations, and they want best practices for getting the most from these teams. Ultimately, however, they want a picture of what the PM team should be.

Individual pieces of research fill out some details. However, these details don't always add up to the complete picture. Or, to look at it another way, you need a rough sketch of the family portrait before you fill in the details for each person.

That rough sketch is vital for answering many common questions, such as the PM's relationship to an Agile team. If you choose the "PM as product owner" option, that won't necessarily tell you everything you need to know about the tasks that person performs, who takes care of the PM-like tasks that are now off that person's plate, and what skills and experiences the hybrid product manager/product owner needs to succeed. While a snapshot of the individual PM might be useful, a family portrait that includes other roles and responsibilities is even more helpful.

The Profiler provides that rough sketch. You won't find many (or perhaps any) tool like it, which is why it took a long time to build. It was worth trying to build one, even if the experiment turned out to be an utter failure.  If we know that you can't create the rough sketch, you'll continue working on separate pieces. It's then up to the reader to build a mosaic of the pieces, in no particular order.

On the other hand, if you can build the rough sketch, you can tell right away which areas will need the most attention, and how they affect adjacent pieces. If Rembrandt hadn't the whole composition of The Mill worked out in advance, he would have wasted time on sections of the canvas that, in the end, make the central subject as striking and interesting as it is.

[Cross-posted at The Heretech.]