Over the years, we have encountered scores of cases where it was unclear whether a task or deliverable was the responsibility of product management (PM) or user experience (UX). As UXers, we have often thought that the UX roles were not defined well enough to be understandable by UX professionals or by people in product development, and that caused misunderstanding in responsibilities. We’ve also heard our PM friends complain about the ambiguity of a UX job and how UX professionals do things that are PMs’ responsibility.
To understand how user experience professionals and product managers see their roles and how the roles relate to one another, we conducted a survey looking at PMs’ and UXers’ expectations about who should be responsible for various common activities related to these professions. As you will see in the detailed data charts, we found many cases where UX and PM professionals disagreed about who is supposed to do what. Or, for a summary of our findings, you can always jump directly to the conclusion.
Our Research
Our survey of UX and PM professionals aimed to answer these questions:
- Do other roles overstep on the work of PM and UX, and, if so, how often?
- Which roles overlap with PM and UX?
- Why does duplicative work happen?
- What are the effects of work overlap?
- Who do PM and UX think is responsible for which activities and deliverables?
- Who holds the power at the organization?
The last two questions are discussed in this article. A companion article covers the first four.
The analysis in this article comes from 372 responses from professionals who described their primary role in either UX (279 people) or PM (93 people). The entire survey included more than 500 responses from people working in a variety of roles in product development.
Most respondents (60%) have worked in the areas of PM or UX for 3–10 years, 21% for less than two years, and 19% for more than 10 years.
Most respondents (54%) were from the United States; the next biggest group (27%) was from Europe.
PMs and UXers Are Not Aligned on Who Should Be Responsible for What
We asked our respondents to tell us who they think should be responsible for several frequently done activities associated to both UX and PM:
Survey question: Many things are worked on collaboratively as a team. But for many activities and deliverables, someone has the 'final say' or is most responsible. For each of the following activities, which role do you feel should be most responsible? Roles: content, CX, development, marketing, product management, product owner, QA, support, UX, or other. Activities:
- conduct discoveries
- conduct user interviews
- conduct user testing
- ideate, and ensure the team ideates, on new design ideas
- prioritize user needs in the design
- define the IA (information architecture)
- define task flows in the UI
- wireframe or sketch the UI flow in very early design phases
- make UI prototypes
- decide how a design will look and feel
- create the final visuals in the UI
- decide which areas the UX team will research
- decide which features the UX team will design
- determine which content goes in the UI
- ensure that user research and responding to findings is part of the roadmap
- communicate the voice of the customer to the product team
- explain the design to leadership
- get buy-in for the design from stakeholders
- gather business (executive leadership) requirements for the project
- create the product vision
- prioritize business needs
- decide the product requirements
- ensure the project is meeting business requirements
- create the product roadmap
- decide which features will ultimately be in the product
- decide which features developers will code
- maintain the product backlog
- prioritize customer needs
- track project process to deliver on time
- estimate whether the product or service will meet revenue goals
- understand the product's competitive position
- champion for the product internally and externally
- report product status to leadership
We carried out statistical test to understand whether, for each activity, there was a significant difference in the attribution of that activity to a role between UX and PM respondents. In what follows, all the differences discussed are statistically significant (at p <0.05) unless otherwise indicated.
Tasks Related to UX
PM and UX did not agree on who should be responsible for the following key UX tasks:
- conducting user research
- design work
- defining the information architecture (IA) of the site
- managing design-related work
- communicating design and customer knowledge
- deciding content
Conducting Research
Our results show that even though both most PM and UX responses assigned user interviews and user testing to UX, the extent to which they did so differed significantly. The biggest disagreement was related to discoveries, but even for traditional UX tasks such as user testing there were significant differences, with only 46% of the PMs considering this activity as a UX activity.
One UX respondent wrote about issues caused by people doing research when they are not skilled at it: “UX Research done by non-researchers often does not meet our quality or process standards, resulting in user testing, findings, and recommendations that are not reflective of actual user behaviors and negatively impact the product. If these recommendations are acted on and fail, then it negates the positive work the research team and I have or will provide.”
To be clear, neither team has to completely own any research methodology — rather, methodology can be shared by many roles. However, if PM and UX are not aligned on who should be responsible for what, it’s likely that the work will be duplicated, there will be confusion, and people will feel dissatisfied.
It’s also important that people in all roles fully use their skills and are responsible for work related to those skills. A UX respondent wrote how his team is underutilized and how that propagates misunderstanding and lack of appreciation for UX: “Most of us feel that we could provide way more value and be more satisfied with our roles if we were able to put in practice all research techniques as those will lead to solutions that solve our users’ needs. But as we cannot do so, the perception of other stakeholders does not and won't change.”
Design Work
When it came to design work, we found both agreement and disagreement between UX and PM respondents.
Agreement. For the following 3 design-related tasks in the survey, PM and UX agreed that they should be UX’s responsibility:
- decide how a design will look and feel (82% PMs and 80% UXers thought it should be a UX responsibility)
- make UI prototypes (82% PMs and 88% UXers said it should be done by UX)
- create the final visuals in the UI (79% PMs and 78% UXers assigned it to UX)
Disagreement. Both PM and UX tended to assign the following activities to UX, but UX respondents did more so than PM respondents:
- ideation
- defining task flows
- wireframing and sketching designs
- prioritizing user needs
In particular, the biggest disagreement was on ideation and prioritizing the user needs in design: they were considered the responsibility of UX by more than three quarters of UX respondents, but only by about a third of the PM respondents, with another third assigning them to PM.
Design should be collaborative. UX, PM, development, and most other roles should absolutely contribute to design. But the survey question was about who should be responsible, not involved. If it’s not clear who is responsible for design activities, it is difficult to drive and finalize designs.
One UX respondent’s comment expresses a commonly shared sentiment about people without UX skills doing design: “My boss, a senior UX manager, is famous for consistently saying, ‘Everyone is a UXer.’ Imagine being an accountant, a doctor, or a CEO and someone saying that? This mentality that the role is meaningless is disrespectful to employees who have spent years in the field. I think it's partially because UX is such a broad term that it opens the door to this type of negative behavior.”
Information Architecture (IA)
PM and UX respondents also disagreed on who should be responsible for defining the information architecture of the site. The majority (50%) of product managers believed that development should be responsible for IA and only 27% of them thought it should be part of a UX job, while 75% of the UXers believed that UX should be responsible for IA.
While code architecture is certainly development’s forte, creating the categorization and hierarchy of information in an app is the work of an information architect, which is a UX role. UX has the ability to study — with methods like card sorting, tree testing, and click testing — how to place and name links and commands in ways that make sense to users.
Managing Design-Related Work
PM and UX respondents also had diverging views on who should manage design work. Generally, the majority of PM (around 50%) respondents felt that these management activities should be the responsibility of PM. In contrast, UX respondents’ views were more diverse, with some assigning them to UX, some to PM, and some to product owners (PO). Interestingly though, for all these management activities, the most common response among UXers (more than 38%) was that UX should do them. In general, the data shows a tendency for both UX and PM roles to appropriate management work related to design.
Deciding which areas the UX team will research was the clearest example of appropriation: UXers thought UX should do it and PMs thought that PM should do it.
It’s easy to understand why UXers and PMs are misaligned on who should do these activities: these tasks have a clear management component and also a clear user-related component, so by definition, they are ambiguous. That’s why it’s very important for organizations to explicitly remove the uncertainty and establish guidelines about who should do these activities. These are some of the toughest decisions to be made in software-development processes, even without ownership questions. You can almost imagine PM and UX people pointing in all different directions when asked these questions.
Communicating Design and Customer Knowledge
In this area, we also found wide misalignment between PM and UX. UX respondents tended to also appropriate all these activities (with at least 49% of UXers assigning them to UX), whereas PMs had more diverse views regarding who should do them.
Communicating the voice of the customer to the product team was the activity in this category that PMs were most divided about — some PMs (25%) thought it should be PM’s job, others (29%) that it should be CX’s job, and 16% of PMs thought it should be assigned to PO. Only 9% of PMs assigned it to UX (compared with 54% of the UX respondents).
For the other 2 activities (explaining the design to leadership and getting buy-in for the design from stakeholders), we also saw appropriation from PM respondents: most PMs thought these activities should be the PM’s job (45% and 53%, respectively), but the next common PM response was that they should be UX’s job (29% and 23% respectively). These findings show the disconnect between UX and PM when it comes to who should be responsible for selling and explaining a design. No matter the roles involved, it’s not a good idea to have someone else other than the designer pitch a design — the presenter may not properly understand the reasoning behind each decision and may not accurately convey feedback back to the designer. Moreover, this type of scenario (where PM presents designs to leadership and stakeholders) robs UX from an opportunity to become visible in the organization and, in the long run, can decrease the trustworthiness and growth of the UX role, UX teams, and UX professionals.
The relationship between CX and UX is also sometimes unclear. These departments were originally separate, with CX in charge of other nondigital interactions and customer feedback. With the newer CX transformation going on today at many organizations, the distinction between these areas becomes blurry and it’s important to define and separate their responsibilities very clearly.
Deciding Content
PM and UX were also somewhat misaligned on who should decide content: they both tended to attribute it to either UX or content people, but PMs tended to ascribe it more often to PM (23% of responses) compared to UX, who only assigned it to PM in 5% of the cases. (The other differences between the percentages of PM and UX respondents assigning content to different roles were not significant — for example, even though 28% of PMs vs. 41% UX assigned this activity to UX, this difference was not significant.)
Like designing screens and workflows, deciding on content is an activity that many people believe almost anyone can do. Many can, indeed, write, but most can’t write well for digital media. However, the disagreement about who owns content was among the minor ones.
Tasks Related to Managing Projects
PM and UX did not agree on who should be responsible for the following key tasks related to managing projects:
- product vision and prioritization of business needs and product features
- managing the project and measuring outcomes
- evangelizing the product and the team’s output
- understanding competition
Product Vision and Prioritization
The majority of PM respondents (over 63%) considered that all the tasks related to vision and the prioritization of business needs and product features should be their responsibility. In contrast, UXers were usually split between assigning these tasks to product owners and assigning them to product managers. For all these tasks, more PM respondents were likely to assign them to PM than UX respondents. In contrast, more UX respondents were likely to assign these vision and strategy activities to product owners than PM respondents — with the exceptions of deciding product requirements and of deciding which features should be implemented by development, where the differences between the percentage of PMs assigning it to PO and the percentage of UX assigning it to PO were only marginally significant (p=0.054 and p=0.09, respectively).
Overall, it seems that UXers do not have a clear understanding of the different responsibilities of product owners and product managers when it comes to product vision and strategy, and a clear, transparent differentiation of these roles throughout the organization will benefit towards creating common ground.
Before Lean and Agile became popular and introduced the product-owner role, the project manager role, which was usually a software-engineering manager, ran the project and its schedule. Program managers were also fairly common, had a more administrative role, and took care of operationalizing work. Today’s product owner often seems to take on (most of) the tasks of the project and program manager of the past and be the custodian of Agile ceremonies. But, with the product owner’s role potentially being so large, it’s possible that product managers need to occasionally do some of these tasks, and this overlap probably causes some of the confusion about responsibilities.
Managing the Project and Measuring Outcomes
Overall, even though both UX and PM respondents tended to assign the following tasks to PM, the extent to which they did so generally differed:
- Maintain the product backlog: More PMs than UXers tended to assign the product backlogs to PM, but the difference between the percentage of PMs and the percentage of UXers who thought it should go to product owners was not statistically significant.
- Track process to deliver on time: This task was the only one that was assigned to PM more often by UXers than by PMs. The difference between the percentage of PM respondents and the percentage of UX respondents who thought it should go to PO was not significant.
- Estimate whether the product should meet revenue goals: Even though a larger percentage of PMs than UXers (59% vs. 48%) assigned this task to PM, this difference was not statistically significant (p >0.1). However, more UXers than PMs thought that this task should go to PO (and this difference was statistically significant).
- Ensure the project meets business requirement: PMs thought this task should go to PM, but UXers assigned it to PO. Both differences were statistically significant.
Overall, in this category the biggest misunderstanding was relating to who should ensure that the project meets the business requirements. UXers were more likely to confuse the attributions of PM and PO. Again, there should be a clear differentiation between PM and PO.
Evangelizing the Product
PM respondents tended to appropriate the activities under this category, but UXers were divided between assigning them to PM or to PO. Overall, more PMs than UXers assigned the tasks to PM and more UXers than PMs assigned them to PO. Most UX responses (41%) thought that PO should champion for the product (in contrast with the majority of PM responses, who assigned that task to PM). While the majority of both PM and UX respondents said that reporting product status should be done by PM, more PMs than UXers assigned it to PM (72% vs. 53%) and more UXers than PMs assigned it to PO (40% vs. 22%).
Competition
PM and UX respondents also had different understandings of who should research the competition for a product. PMs appropriated that task, but UXers were divided in assigning it to PM, PO, or marketing. More PMs than UXers assigned the activity to PM and more UXers than PMs assigned it to PO. Comparable percentages of PMs and UXers assigned this task to marketing (21% vs. 24%; the difference was not statistically significant, p > 0.1).
Power of Roles
The idea of power is relevant because, theoretically, those in powerful roles can influence or do the job of less powerful roles if they choose to do so, and the less powerful roles may not be able to do much about it.
To understand how UX and PM professionals perceive the balance of power at their organization, we asked the following question:
Survey question: Which of the following roles has the most power at your organization? Please rank the roles in order of their influence, with 1 being most powerful and 10 being least powerful. Each number may be used only once.
We calculated the average rank for each of the roles, as assigned by PM and UX. Overall, the two groups of respondents ranked all roles very similarly. The only statistically significant difference (by a Wilcoxon-rank test, p <0.05) was that the product owner was ranked higher by PM than it was by UX.
Product Development Roles Are Not Universally Defined
It is possible that a person who is formally hired in one role could be skilled in and responsible for tasks that are traditionally done by a different role. For example, a startup may have a product manager and developers, but no UX person. In this case, all research might be done by the PM and design may be split between PM and developers. Startup or mature company, product development roles are not going to be defined in the same way at all organizations, so our survey respondents may have experienced varied assignments for the tasks in our questions. They probably answered our survey based on their experiences and ideas of what may be the most effective, even if far more effective task assignments could exist.
In recent years, some development teams have moved focus on hiring for skills rather than roles. A gap analysis of team skills may show that the team needs people with skills that span multiple traditional roles. So, for example, instead of needing to hire a product manager or a visual designer, the team may instead need someone who can create a product vision or can build a high-fidelity prototype. Such a low-granularity, skill-focused approach to staffing may be more flexible than a traditional role-based one.
For individuals, it means that, no matter what their job title, they may have the opportunity to vary the tasks they do in their job. Mastering a diverse set of tasks can be gratifying, stimulate employee growth, and help organizations retain great employees.
On the flip side, there are negative points to this kind of job variety, such as:
- Less practice: Someone may not fully develop a skill if they don't do it frequently, so their output may be of lower quality and take more time to produce.
- Lack of awareness: Enjoyment is not a skill. Just because people relish doing something or see a need for it does not mean they are good at it. There seem to be a lot of people who enjoy doing UX work.
- Missing expertise: UX is so nuanced that it can be difficult for nonUX people to know when UX work is done well or not. Someone who can’t write code isn’t going to try to do an engineer’s job. If they do, they will not get very far. Someone who isn’t privy to the business goals and constraints isn’t going to create a product backlog. If they do, nobody will follow it. But anyone can download a wireframing tool and start sketching, or sign up for an online user-testing app and launch a study. Maybe they will even do a great job. But they often will not know when they did a substandard job. And therein lies the rub. Even though UX activities have a low-entry cost, the likelihood that someone with little experience or training will do these things well is also low. And the likelihood they’ll do it better than a trained or experienced UX professional is even lower.
- Decreased efficiency: There may be someone else at the organization who can do the job better and faster. For example, a UXer may be able to workshop and derive a product vision, but a PM may do it more thoroughly and get the right high-level stakeholders involved. A PM may be able to sketch an early design flow, but an experienced UX person would consider design principles and take advantage of user data and knowledge they may have previously gathered.
- Difficult Hiring: If the skills the team needs are varied, it can be difficult to find someone who has that particular skillset.
Business leaders balance the desire for efficiency in work with the need to motivate and retain good employees. Making job descriptions loose leaves room for an individual’s variety and growth. But, duplicative or subpar work are among the possible risks associated with leaving roles undefined. These can be mitigated if boundaries between roles have been made clear, which requires more, better communication from leaders and between individuals.
Conclusion: Align on Individuals’ Responsibilities on Your Project
Every organization has its own culture, job roles, and way of working. And many individuals are not boxed into doing the same few activities traditionally associated with their job title. However, it is disconcerting that PMs and UXers have very different views and did not agree on much in their assessments of who should be responsible for key areas related to design and managing projects. In fact, almost all responses about responsibilities were different.
Some of the biggest misunderstandings surrounded research, namely who should do discoveries, ideate on new designs, and determine task flows in the UI. Deciding what work UX should do, like which features the UX team will research and design, was also a point of misalignment. And communicating design, such as explaining the design to leadership and getting buy-in from stakeholders, were other areas of disagreement.
For all of the aforementioned areas and then some, PMs believed they were responsible while UXers believed they were. This was an interesting and clear example of appropriation, the tendency by PM and UX to believe that everything was their job.
On the other side — PM tasks and responsibilities — UX respondents were often confused by the differences between product management and product ownership, particularly for tasks such as product vision and prioritization of business needs and product features, evangelizing the product and the team’s output, and understanding competition.
What is there to do about this lack of sync? We could recommend a gargantuan project to standardize the world’s job descriptions for product managers and for every UX role there is. But by the time we finished creating descriptions that could be applied so broadly, the world would have already changed and the descriptions would no longer work. It would be like mowing the grass a massive property. By the time you finish, the grass is already long in the fields where you began and you need to start over.
So today, in the earliest phases of projects, PMs and UXers should truly sync up on research and design, and say specifically who will be doing discoveries, ideation, early sketching, and design workflows. Not only will syncing up on these mitigate some of the biggest pain points, it will set a stage at the beginning of the project for communication, delegation, and boundaries.
Throughout projects, clearly asserting the tasks that each individual should work on can help people excel and feel confident in their job. Each person should know what they are supposed to be doing on each project or at each point on the project. Also, other members of the product team should know those responsibilities, too. Clear definitions will probably increase collaboration between functional groups, and eliminate the feeling that ‘I have to do everything.’ If everyone will know who to go to for what, work with probably be more gratifying, productivity will increase, and outcomes will improve.
Do you have advice or a story about how UX and product roles work well together? Share it here. We plan to write another article with the compiled advice. Take our course, Product and UX: Building Partnerships for Better Outcomes to get an adaptable framework for aligning and defining who does what on specific projects and throughout the product development lifecycle.
Share this article: