Skip to main content

User Experience and Product Management

Jeff Lash pointed me to a couple of articles that he and Chris Baum wrote about transitioning from user experience to product management. You can read the articles here:

Part 1
Part 2

A user experience professional is someone who designs a product's user interactions and/or interfaces. This role is sometimes called "interaction designer" or "information architect".

Jeff and Chris note:
The most common conflict between user experience and product management roles comes into play when discussing what the product should do and how it should do that. There are often arguments about who should be responsible for defining the features and functionalities of the product. Product managers feel as though they should be responsible since they manage the product, but user experience professionals feel as though they should be responsible since they spend time researching user needs and interacting directly with customers and users.
I have a slightly different take on this issue.

Since one of the primary responsibilities of a product manager is to thoroughly understand the prospective users of the product, it's natural to conclude she should design the user experience. Yet a primary responsibility of an information architect is to be an expert on the principles of user experience and how to maximize usability. So it's also natural to conclude that information architects should design the user experience.

Jeff and Chris resolve that the product manager is the final arbiter:
Ultimately, since product managers are responsible for the overall success of the product, they are the final arbiters of what the product should do. A good market-focused product manager understands the market context and customer needs and makes appropriate decisions about features and functionality based on first-hand experience and all available research.
but that the product manager should take input from user experience specialists:
Good product managers understand the role and importance of user experience specialists. They value their input and use their research and recommendations to create good products. Just like the president takes advice from cabinet members, product managers should use their cabinet members—user experience, marketing, technology—to inform decisions that they need to make.
I resolve the apparent conflict a bit differently than do Jeff and Chris. To me, the user experience responsibilities of a product manager and information architect are as follows:

A product manager frames the usability metrics. What usability problems do users need to solve or avoid? Are they afraid it will take too long for them to learn to use the product? Are they afraid it will take too long for them to accomplish their functional goals? Based on his understanding of users, the problems they are trying to avoid, and their tolerances, a product manager specifies the ways of measuring these aspects of usability and places constraints on them that will be acceptable to the user and the market.

An information architect designs the user interactions and interfaces that will satisfy these usability metrics. How will the user interact with the product to achieve her goals? What interface will the product present to the user? An information architect answers these questions by fleshing out use cases and composing screen mockups.

Some product managers have a knack for information architecture and can play both roles. Either way, the two roles should work together for the best chance of product success.

Comments

Jeff said…
Great insight, Roger. The extra part that you've added on to this for me is the idea of putting metrics around the specific usability objectives. I'm used to framing the market problems, the user goals and needs, and the challenges users face with my product and with others, but in most cases there aren't any specific measurements around them. It's a good way of looking at creating more specific goals for a design, so that it's less subjective and more objective whether the design works.
Roger L. Cauvin said…
I look at framing the usability metrics as part of the product manager's responsibility in defining the product's requirements.
zap said…
The other thing I like about Roger's framing the usability metrics point is that it moves the focus back to results, away from process. In my experience, a lot of conflict starts when the product manager tries to own too much of how a problem should be solved, rather than holding the team accountable to explicit outcomes they need to achieve and letting them figure out how to best do it. That mistake sacrifices the process expertise of the UX specialist. A product manager that focuses on framing the outcomes in the form of usability (and other) metrics makes room for the UX designer to contribute more of his wisdom on *how* to get to the product to meet the goals.
Len said…
Nice article. You are thoughtfully examining the relationship between UX and PMs and I like the concept of usability metrics and followed the link to your earlier post. I bristle at the "number of clicks" metric simply because it diminishes the work of a UX expert. Fewer clicks will likely be a side effect of good usability, but I don't like it being a primary measure UX success, especially because for many PMs don't have the resources to legitimately test the "time it takes" metric that you mention and as a result will rely too heavily on the number of clicks. This often results in interfaces with tons of buttons which gives the users headaches.

One other possible metric is "training required?"--do users of different levels require training, and if so , how much?

What other metrics do people use?

Follow me on Twitter: L3n
Unknown said…
Great post - helps to illuminate one of the many functional overlaps that happens between product managers and other disciplines.

That said - and coming from an IA background - I think it's overreaching a bit to saddle product managers with framing the usability metrics. This isn't to say they shouldn't be involved - I would absolutely expect a product manager to help frame the "what" here in reference to understanding the business and market needs. But in terms of defining the usability problems, measuring interaction, etc., I view the IA as taking lead, with product managers providing support.

On the design front, it's important to note that an IA will also be working closely with a graphic designer to help determine the "how" - the IA is not the sole arbiter of the interface, as defining the interface is a collaborative, multi-disciplinary process. I view the IA and product manager (and engineers as well) as participating here to make sure the "how" (the design) meets the requirements for the market, business cases, usability, and technical needs.

All that said, every team will have shades of gray here. To the extent that product managers have or want to develop skills along the IA path, I wholeheartedly agree that this will be a benefit. Additionally, IA's should be enlightened about the business and market needs for the product, as this allows them to make more informed decisions in their work. I would strongly recommend that product managers without a good IA on the team go about finding one quickly... or start doing *a lot* of reading. ;) Good collaboration between these groups will be essential in delivering a successful product that meets the market and usability goals.

-David
@thedavidbase
Roger L. Cauvin said…
David, thanks for your comments regarding the shades of gray and the expertise needed to frame usability metrics.

I agree that, at least initially, the product manager will not be able to frame usability metrics without consulting a usability expert.

However, the framing of metrics (clear and measurable requirements) is precisely the product manager's job. When framing metrics around any attribute (whether usability, availability, internationalization, etc.), a good product manager will consult with experts to determine those metrics. Usability is no different.
Joe said…
I have to say I agree with Jeff and Chris and largely disagree with you, Roger.

The user experience team is responsible for the user experience. That responsibility includes user research, information architecture, information design, interaction design, visual design, and usability.

The product manager is responsible for the overall success of the product, taking into account user, business, and technical constraints and capabilities. But to say the product manager "owns" the user experience is overreaching at best.

Clearly, the product manager is a decision maker. But that decision-making should reside only within the sense of "what is good for the product"--the UX team (lead, director, IxD, whatever) decides "what is good for the user."

Again, it's a dance, it's a collaboration, and it's an approach. I strongly suggest we resist the slippery slope of eliminating UX and residing those responsibilities in product management.

Let UX do their work.
Roger L. Cauvin said…
Joe, I never contended that the product manager "owns" user experience. On the contrary - the whole point of this blog entry was to leave the design of user experience entirely in the hands of user experience designers.

By researching the market and understanding users and buyers, a product manager knows what sorts of usability are necessary for product success and defines how usable the product must be. Designers apply their creativity and expertise to satisfying those usability requirements.

Usability requirements do not include interaction design or user experience. They simply frame the usability metrics that the design ultimately must satisfy.
Joe said…
Sorry for the seeming overreaction, Roger. Mea culpa.

I've seen experienced where a UX lead describes how a product should work, based on user research, and the product manager overrides that person on the basis of a more marketing-driven or tech-driven approach. I do like the approach you are mentioning, and I also like the (newish) focus on product management as a core competency. I think it helps all of us.

I do feel that UX should lead user research. Let's agree on that and we can have our own kumbaya moment ;)
Roger L. Cauvin said…
Joe, I wouldn't necessarily agree that a user experience designer should "lead" the user research.

User research is first and foremost about understanding the problems users face (and not just in the realm of usability). This activity is precisely where a product managers talents and skills lie.

That said, as a UX designer, you are talented and skilled in UX design. You recognize the importance of understanding the usability needs and "personas" of users and getting further context than the product manager can relay. Thus it makes a lot of sense to collaborate with the product manager in engaging and studying users.

To summarize: part of a product manager's role is to understand the overall needs (of which usability needs are an important subset) of users. But a UX designer benefits greatly from direct contact with users, particularly when validating candidate designs.

Either way, a product manager shouldn't "override" designs if they meet the requirements (i.e. satisfy the usability metrics she has defined).

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio