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.’”
Whoa! My description didn’t describe me managing anything. Why should my description of “interaction design” ever correspond to anyone’s notion of “product management?”
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.
My earlier article, Putting people together to create new products, included this diagram showing how the different groups have different domains.
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.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.