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

Use Case as a Black Box

Consider the following use case: Purchase Items Actor: Purchaser Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40. Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased. The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items. What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement . Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint: Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the