Where do product managers fit?

Jonathan Korman

September 5, 2004

People often ask how interaction designers should fit into their companies.
If the company cannot take good advantage of it, the most brilliant interaction
design in the world won't help as much as simple, workmanlike interaction
design will benefit a company that uses that design well.

To talk about putting interaction designers into your organization, it helps
to start by talking about some other people—product managers. In the
past several years, many companies have started introducing a product management
(PM) role into their organizations. The way PMs play out at different companies
often varies dramatically in what PMs do day-to-day, in how PMs fit into
the organization, in what skills and background the company expects a PM
to have, and so on. But most organizations agree at the most fundamental
level about the PM's charter: the PM has responsibility for ensuring a product's
success.

Hard questions about product management

PMs face a range of challenges. A few organizations frame the role in such
a way that it becomes obviously difficult for the PM to succeed. They may
give a PM responsibility for too many disparate products, or too little support
from above for their authority, or unclear divisions of responsibility with
other people in other roles. More often, though, companies have not made
mistakes so much as struggled with hard decisions about how to define the
PM role.

For example, many companies have internal disagreements about whether to
place the PM as part of the marketing group or part of the development group.
Putting the PM into marketing makes sense, since the ability to win customers
for a product very directly measures the product's success. But putting a
PM within marketing can cost the PM credibility and effectiveness in the
development group that actually creates the product, compromising the PM's
ability to affect the shape of the product itself … which of course
has a direct link with the product's success or failure. On the other hand,
putting the PM under development makes it hard to keep the PM connected to
customers' needs and responsible for the product's sales success.

This conundrum suggests that the PM might best stand outside of either group,
but this presents its own problems. Working relationships become hard to
define. If you have a big, complex product, then the product has both a development
lead and a marketing lead.

How does the PM fit together with those? As a peer? How, then, does the
PM act to control the product, without authority over marketing, development,
or anyone else? As their superior? How, then, does the PM interact with these
leads' superiors within the development and marketing groups?

Who does a product manager manage?

The interaction design connection

To answer that question, let's bring interaction design into the picture.
When I describe what I do to people who have not encountered the term "interaction
design" before, I say first that "I look at users' needs, figure
out what kind of product best addresses them, and create a behavior specification
for that product which the development team then uses as requirements to
drive their work." Often people say, "In my organization, we call
that a 'product manager.' "

This connection surfaces because organizations see that the description
of product requirements strongly affects whether the product will succeed … and
they recognize that the development team won't actually follow requirements
that don't have the backing of management authority. Thus the person who
drives the decisions of the development group by setting requirements must
become a "product manager," placed in the organizational hierarchy
at or above the level of the development lead. So even though the PM doesn't
manage the people in either marketing or the development team, we call that
person a "manager" as a way of denoting their level of authority.

In practice, the term "product management" does work well as a
descriptive title because PMs concern themselves with a product and in fact
do management as their day-to-day work. They talk to people in the organization,
individually and in meetings, offering information and making decisions.

What does this have to do with talking to users, figuring out behaviors,
writing requirements—the stuff of interaction design? In an organization
lacking an explicit interaction design role, many PMs recognize that as the
owners of product requirements, they have to also author those requirements.
The development team cannot author their own requirements, the marketing
team typically cannot write requirements that serve the development team
well, and executives above the PM will not set requirements at the necessary
level of detail. So the PM must do it.

But a problem emerges: the work of interaction design—all of that
talking to users, solving interface problems, writing detailed requirements
documents—takes a lot of time and effort. Doing this work thoroughly
takes more time than a PM can spare from the work of managing. Plus, few
people have strong skills in both management and design. Either the PM's
management work suffers to spare time for interaction design or the PM's
interaction design work suffers to make time for management. This spells
frustration for the PM and problems for the company.

The interaction design role

Thus the organization really needs a separate person with a distinct role
as an interaction designer (IxD). The work of interaction design done well
demands so much time, attention, and skill that it takes a person's full
attention as a full-time job. (Indeed, at Cooper we find that a team of two
or three IxDs works much better than a lone IxD.)

Does this mean that you need IxDs instead of PMs? No. You still need management
authority supporting any behavior specifications that IxDs create. Anyone
with management authority will end up doing management work, which becomes
incompatible with interaction design work.

This distinction also helps to keep interaction design from becoming too
important. Good IxDs think in terms of users' needs and advocate for them.
But though addressing users' needs plays a very important role in determining
product success, many other concerns have at least equal importance. You
need a product that you can make and sell at a profit. You may have a gatekeeper
customer making purchase decisions, someone quite different from your end
user, who needs to see some characteristic in the product that does not matter
to users. You may have partner agreements to satisfy. And so on.

The PM must weigh and integrate the various elements of success. If that
PM also has responsibility for the interaction design, then either their
effectiveness in product management or their effectiveness in interaction
design will suffer because of their divided priorities.

Working relationships

Without IxDs, you have PMs in the Dilbert situation of trying to arbitrate "he
said, she said" disagreements between development and marketing. The
addition of IxDs creates a completed system of groups with interlocking concerns
and responsibilities, giving a PM the ability to make informed decisions
about product strategy because she has people speaking for all of the components
of product success.

The organization thus considers these three groups as peers, separate from
one another, but all working at the direction of a PM. The PM manages these
three groups, receiving information from all three, giving them direction
about how to use their time, coordinating their efforts.

Product creation

Consider how product creation works in this kind of organization.
The company may start with a market they want to serve, identified by the
marketing group. IxDs talk to users in the space, identifying a few different
classes of users and spotting opportunities to serve them with new products.
Marketing turns around and takes those classes of users and connects them
with customer demographics, determining how much potential revenue those
users could represent.

Meanwhile, the IxDs take what they learned about users' needs, market requirements,
and technical constraints (from talking to users, marketing, and development,
in turn) and put together a product definition, describing its behaviors
in detail in a behavior specification. Development then takes that behavior
specification and produces a technical specification and a development timetable.

Now the PM has the information available to make intelligent business decisions.
She can ask marketing, with a well-defined product and intended audience
for it, how much money can we expect to make with this product? She can ask
development, what time, money, and resources will it cost us to make this
product? She can ask executives, does this product match our vision for the
company's business?

The PM can now act to integrate the concerns of the different constituencies
in the organization. For example, if developers express concern that an element
of the designed product will take a lot of time and money to build, the PM
can then ask if it makes sense to defer that component to a later release.
Development can answer what the costs become, breaking the product into multiple
releases. IxDs can answer whether the more limited, early release product
will still satisfy users, and what a more limited product will look like.
Marketing can answer the impact on customers, revenue, and marketing the
multiple-release strategy.

Each of the groups owes information to the PM, who then in turn makes decisions,
and can hold the group accountable for executing on those decisions. IxD
provides a clear picture of target users and product behaviors, and has accountability
for user satisfaction. Marketing turns target users and product definition
into a marketing plan, and has accountability for sales. Development turns
a behavior specification into a development timeline and a finished product,
and has accountability for robust engineering and meeting their promised
timeline.

The PM, in this world, not only has a charter to deliver a successful product—she
has the ability to actually deliver one.