Where Should PM Report?

A perennial problem for Product Management (PM) is finding the right organizational home. In companies large enough to have a PM department, it has a tendency to oscillate between Marketing and Engineering. Two root causes for this are role confusion and organizational distance. Let’s walk through each in turn, while trying to map a PM’s place in the grand scheme.

What’s in a Title?

Most companies have very few Product Managers, and their actual jobs vary widely. Typically, without enough PMs to form a separate department, these lonely few work in an organization that doesn’t understand them. So, a first step would be to define a couple of the roles that are not Product Management, and tighten up the job boundaries. (This is my ideal division of labor. Others are welcome to object.)

Program Manager, aka Project Manager: This is the person who owns Engineering’s master PERT chart.

She is responsible for knowing the status and timeline for every phase review, feature, manual, QA cycle, code check-in, and step in the release process. The best program manager can tell you to the day how late your software project will be. A master of resource allocation, she will present complex trade-offs within the project. (“If we QA the external interface before the database routines, we can start writing the user guide nine days earlier but may slip the synchronization feature…”)

Typically, the Program Manager offers up difficult choices to someone outside Engineering, since these choices will have customer impact and political ramifications.

Product Marketer: This is someone in Marketing who must make your products sound attractive. His goal is to help Sales sell more stuff. This often includes a daily battle to make the competition look weak, and to justify the “right” answers on customer RFPs. In the hunt for revenue, it’s hard to stay pure or objective – and easy to believe in the customer’s ability to be fooled. Trading away the future for the present is irresistible. The best product marketers know how to make lemonade out of under-ripe products.

What’s missing between these two roles is a decision-making role. The Product Manager is the brave soul who has to balance competing interests and take a stand. In the midst of uncertainty and unpredictable outcomes, the PM has to drive choices every day. In the course of a morning, a good PM will have to weigh in on:

  • Our Omaha account team says they can sell 25 units if we commit to a LINUX port for January. They need an answer before Noon.
  • Double-byte Chinese character support is behind schedule. Should we delay final shipment or push this feature to the next maintenance release? What’s the revenue impact?
  • Which of these ten bugs are show-stoppers?
  • Citibank wants a look at our unpublished internal interfaces.
  • What if we bundle all three of these products together and increase the price?
  • Let’s save money by shipping manuals on CD only, and not including hard copy manuals.

Often, the PM is a proxy for the customer. This means taking positions of long-term benefit to the company (e.g. happy reference accounts) instead of short-term ones (e.g. shipping partially tested products).

Ideally, you want your PM to be both right and decisive. It may take years to find out if a decision was right, but indecisiveness can freeze up an entire organization. A great PM recognizes the important few decisions worthy of serious analysis — and plows through the rest.

David Thompson, formerly of iPass and now at PacketHop, taught me that executives are paid to make decisions: a productive day must include least one decision. Meetings, emails, discussions, forecast reviews and brainstorming are secondary to making decisions that drive action. It’s easy to be distracted by the minutiae of business, or by analysis paralysis.

So, we’ve defined the ideal PM: an experienced, decisive driver who understands the customer enough to make complex trade-offs. Now we can tackle the second half of the problem: which organization should “own” product management?

The Pendulum Swings

Perhaps that’s the wrong question. I’ve seen organizations go through an annual cycle: moving PMs into Engineering from Marketing in Year 1, then back into Marketing from Engineering in Year 2. If there were a perfect answer to PM reporting structures, we’d all have found it by now. (Consider diet books. If any could truly offer a solution, we’d all be thin.) Instead, consider the failures that drive this organizational lurch.

When PMs sit in Engineering, they spend their time with engineers. Days are filled with detailed discussion of bugs, development priorities, release trains, and software bundling. Especially in the absence of Program Managers, PMs dive deeper and deeper into the product creation process. This leads to technically good products, but a marketing failure.

Engineering PMs know their features very well, but are weak on benefits and sales materials. They impress technical users at conferences, but don’t know how customers are using their products. They under-invest in competitive analysis and a compelling high-level story. Too much steak and not enough sizzle.

After a year of this, the Marketing VP and Sales VP organize a hostile take-over. Ignoring the objections of Engineering, product managers are moved into Marketing and relocated next to Sales. Suddenly, PMs are spending more time with customers and sales teams, working harder on messages, and educating the field force. They have more time to stalk the competition, writing seemingly neutral white papers to slant public opinion.

Within a quarter or two, though, Engineering is starting to protest. Product requirements now lack detail, development trade-offs are starting to bog down, and engineers are spending valuable time briefing customers. PMs are falling out of touch with schedules and upcoming features. Without daily meetings in Engineering, PMs are becoming “all hat and no cattle.” Here comes the Engineering VP with a new org chart in her hand.

What’s a PM to do?

It’s critical to recognize that product management is an interstitial role, a bridging function between Marketing/Sales and Engineering. PMs own the organizational gap, since they need to deliver real solutions to the customer.

Letting the pendulum swing too far toward either side is a failure. On the westward loop (toward Engineering), PMs must work extra hard to spend time with customers and sales teams. This lets them use the most powerful phrase ever uttered in a lab: “Here’s what this customer told me…”

On the eastbound swing back through Marketing, PMs need to find informal time to hang with the techies. This is outside the stultifying weekly status meetings, or the “everything is still on schedule” nod from the VP Development. Staying fresh with the technology keeps them informed, generates good ideas, and reinforces a sense of the possible. It’s time to replace your product manager when she can no longer sort good ideas from bad. (“What about adding teleportation to our warehouse management software?”)

Said another way, Product Management never really reports up through one function. Good PMs own long-term decisions that routinely cross the artificial organizational boundaries. By representing customers instead of departments, PMs are a unifying force in a divided model.

SoundBytes

When reporting up through Engineering, PMs need to think like marketers. When in Marketing, like engineers. And keep those boxes handy, because another reorganization is coming soon.