9. Healthy Collaborative Tension on the Product UX Spectrum
With it pretty well established that UX practitioners and product managers share many concerns and deploy adjacent proficiencies, this leads to a perennial struggle to define exactly who is responsible for what. There are as many schemes for divvying up the work as there are teams out there, often some variation on this formula:
- The product manager is responsible for the “what.”
- The UX designer is responsible for the “how.”
So, problem solved, right? Short chapter, eh?
But of course even if we agree on exactly what the “what” refers to versus the “how,” exactly how do we apply a rubric like that in practice? Where do you work separately, on what do you work together directly, how do you coordinate, and who has the final say when you are collaborating?
Towards the end of this year Rosenfeld Media will be publishing my book Product Management for UX People: From Designing to Thriving in a Product World (you may sign up there to be notified when it is available for order), the culmination of a multiple-year project that has unfolded with the input and support of the Design in Product community.
During the editorial and production process I am sharing early drafts of chapters, and I welcome any feedback here that will strengthen the material.
The overlap and its discontents
If you remember our product-ux histogram from Chapter 3, you will recall that there are a number of skills in the middle of the spectrum that could plausibly be handled by a UX expert of a PM depending on the team and the context (see Figure 9.1).
The histogram is a conscious effort to avoid the ever-present venn diagrams typically used to show overlap and complexity and to help with scoring, but it can overly suggest a linear order or range among these skills when their relationships are in reality a lot more fuzzy, so when looking at the potential areas of overlap plotting some of these skills in a venn diagram can help illustrate this (see Figure 9.2).
Abilities and skills shared between colleagues are a good thing, of course, and cause no problems inherently, but in practice when there is ambiguity about who is responsible for what or who has the final say on what matter, this leads to conflict, miscommunication, and — most importantly — delivery of poor user experiences.
Conflicts may arise out of simple lack of alignment or for more sinister reasons. There are definitely people out there who still think in terms of “turf” and try to fend off anyone from any other team or school of thought whom they perceive to be encroaching on their turf. This street-gang mentality isn’t great for collaboration but if it exists, you need to be aware of it if you have any hope of shipping great software with the team you’ve got.
Aside from outright arguments about who owns a particular project, artifact, or work product, there is also a strong risk of duplication if product and UX folks pursue their individual agendas in an uncoordinated way.
Each will do research, each will define concepts and models, and each will produce specifications or other design artifacts that attempt to address very similar issues in somewhat different ways, potentially leading to all sorts of problems, including
- ambiguity at the development and delivery stage
- wasted cycles clarifying distinctions that never needed to be created in the first place, or worst of all
- endlessly bouncing back and forth between two framings in an infinite loop of a tug-of-war that ends only when someone higher up the chain notices the paralysis on the team.
Some talk about overlapping areas of responsibility, potential turf conflict, , potential uncoordinated research,
Where do you draw the line?
A while back I posted a question to my network that sounds deceptively simple: “Where do you draw the line between product and UX.” Given my contacts in the “it depends” crowd, perhaps I shouldn’t have been surprised at how many people tried to reject the premise, questioning whether any such lines exist (or should exist at all).
Most people emphasized the gray area of overlap, which is understandable given that that is where all the nuance lives, with replies such as:
“You don’t. You enable each other achieve the best customer outcomes; but to be fair to customers, it doesn’t matter if there’s a line between product management and design or not.” Jeewant Singh Gupta, Product@HSBC
“The better design leaders think like PMs. Some have crossed over. I know many who aspire to. I’m surprised this isn’t talked about more.” Dirk Cleveland, Senior Partner at Riviera Partners
“Are gradients lines? 😬 I draw the line at delivery and skillset, but both practices focus on the same thing; delivering results.” Eduardo F. Ortiz, CEO Coforma
But lines are not bad things! They can give clarity. It’s understandable that people want to avoid sharp boundaries, but this confuses the collaboration layer of work with the decision-making layer.
At the level of working together, yes of course let’s have no lines! Let’s work shoulder to shoulder, looking at the same diagrams and discussing them, handing the marker back and and forth to doodle on each other’s white-board thoughts, writing interview questions and surveys together, but let’s also be clear: The product manager has to decide whether the product is ready to ship. The UX strategist has to make the final decision on the navigation taxonomy. And so on. It’s not that any of these specific task must be owned by one role or the other in the abstract. It always comes down to the specific people involved, not stereotypes, but in each case these matters of ownership and “final say” need to be clarified, understood, and agreed upon by all involved.
“The ‘job’ for the product manager is driving customer outcomes. As a product manager anything that improves or impacts customer outcomes matters to me. Whether the design is researched, tested and developed by someone else or not remains immaterial. As the captain of the ship I should not just focus on steering the ship rather on all the radiators and needles of things that make the ship move in the right direction. If I’m the designer, sure — the line is a beautiful thing — it allows me to focus on things that matter to me from a design outcome and stay true to that.” Jeewant Singh Gupta
From the Trenches
Research & design is about needs and possibilities. What are an audiences needs? What opportunities does that create for the organization? What kinds of solutions might meet those needs and opportunities and how would they work?
Product Management is about alignment, prioritization and progress. What is the org focused on right now? Which opportunities, needs, and solutions does it make sense to focus on right now given the businesses priorities, capacity, and the progress made to date?
Engineering is about stability, scalability, and enabling. How do we build things so that they’re stable and perform well? So that they can be scaled to handle growing audiences and demands? So the at their flexible and can be reused as our needs change? And in such a way that doesn’t become a roadblock for future technologies and needs?
The relationships between these things is symbiotic. Each needs the others for both inputs and outputs. It isn’t an assembly line of one passing decisions on to the the next.
Each (ideally) is an active participant in the conversations lead by the others, not as a limiting factor, but as an enabling one.
~Adam Connor, Head of Experience Research & Design, Elixir
The good, the bad, and the ugly
Before digging a little deeper into how product vs. UX tends to play out these days, let’s take a step back and clarify one point. There is a bit of a gap in the field right now between an idealized concept of fully empowered product management and how the role tends to be practiced in the majority of environments in the breach.
This can lead to some confusing discussions where product management is defined in aspirational terms and the well rounded thoughtful collaborative creative experimental compassionate PMs described don’t seem to match up to the lived experience of UX folks (and others) working with the product people they’ve got. There is a risk, too, of falling in the No True Scotsman fallacy by excluding anybody practicing product management badly (too rigidly, as an autocrat, without UX savvy, etc.) from being a “real” PM, which is frankly a cop out.
A better approach is to acknowledge this range of possibility in practice. There really are honest-to-gosh great PMs out there and well led highly empowered product organizations fostering many great product teams, but this fully evolved model of product management is still the exception and not the rule in practice across most organizations and industries. (If we’re honest, we’ll acknowledge that something like this is also true for user experience, and the idealized model of UX research, strategy, and design often falls short in practice when faced with resource, time, and leadership constraints.)
You can roughly sort real world product/UX relationships into three general buckets:
- The good: teams that have healthy thriving collaboration about product discovery and experience
- The bad: teams where the working relationship between product and UX is faulty and needs work to reach its full potential
- The ugly: teams that propagate and reinforce toxic relationships among the disciplines
The good
The hallmark of a good product-UX relationship is that the roles are clearly defined and well understood by everyone involved. There are many opportunities for collaboration and clearly negotiated “final decision” ownership defined for each shared concern. The biggest challenge here is to preserve this culture as the team succeeds and scales up.
From the Trenches
Matt LeMay reframes this in a way that may be more realistic about how role details get nailed down: “I think that on the healthiest teams, the team’s shared outcomes are clearly defined and well understood. People naturally figure out how to work together towards those outcomes.”
The bad
The vast majority of product orgs live in this “bad” space where folks mean well but haven’t yet done the work to educate themselves about each other’s disciplines, so there is a tendency to miscommunicate or fall afoul of each other’s agendas, as well as a tendency to spring “deliverables” on each other.
The opportunity here is to have those difficult conversations. This can start at the individual practitioner level, when a UX designer or product manager or lead from one of those disciplines speaks up and addresses uncomfortable or awkward truths. When everyone can share how they wish things worked and what they are afraid of, it’s usually not too hard to find alignment around shared goals and interests and to surface, discuss, and come to “working agreements” around the thus-far mismatched priorities.
Working agreements can be thought of as the social equivalent to agile’s “rough consensus and running code.” We don’t have to get it all right in one go. That’s highly unlikely. But we can work out — for now — some ground rules that are acceptable to all involved to at least try, and then we can use our product mindset to retrospectively review and iterate on those working understandings to improve them, through honest airing of what is working well for whom and what is not, which practices are enabling to people to show up at their best, and how well the working agreements handle those inevitable days when any of us are not able to be our best.
Individuals can only do so much. One thriving squad can function as a “bright spot” and an example to others, but to really evolve an entire product organization (no matter the size) at some point you need leadership that is committed to working through these difficult conversations at every level. In a mature org that is finally ready to face these challenge, this may require something like time set aside at a company offsite or a special “Product/UX Summit” occasion with all the personnel involved together, or in the cases of very large entities, a representative sample.
The ugly
There are of course many “feature factories” out there, too, where people with product titles function more as project managers (at best) or overseers at worst, driving technical and design teams on in a command-and-control environment with little agency, let alone opportunities to reframe questions, align projects with overarching goals, or appeal to product vision or organizational values.
One solution for a UXer or budding product manager in such a toxic environment is to run away. Get out of Dodge. Get you a job that nurtures you. But of course that is easier said than done as often as not, and even if you are actively seeking a better opportunity, you may still need to survive and operate in an ugly product environment for weeks and months before escaping to the promised land.
So what do you do?
First of all, you pick your battles. If you go to total war over everything offense large and small against user-centered design or product sense, then you will make enemies and end up either frozen out and told to mind your business or shown the door.
Generally, your best bet is to choose when and where to hold your ground and in those scenarios, use all of your craft skills to communicate why the approach being foisted on you will not work.
Do some research even when you are told to skip that phase. Get some data that hasn’t been cherrypicked to advance one PM’s roadmap item over another and make a case for an alternate approach. Just as the devil can quote scripture with the best of them, data selected to shape a narrative or win an argument will lead you down the path to ruin, no longer helping you see what is really going on and instead reflecting back to you a fun-house mirror that you hope you can persuade other people to take for reality.
When overruled, make sure that goals are defined and metrics tracked and ask for accountability when decisions are proven wrong by the outcomes. None of this will be fun, but it can give you some room to further your own practice with integrity until you can find a more supportive environment.
Where in the org chart?
One matter that can complicate the product/ux relationship is an org chart. Does UX report to product, or are they peer disciplines? Or a little bit of both? That is, are there UX people and product managers reporting up to a head of product (or VP product, CPO, director of product, etc.), but functioning as peers at the individual contributor level? In this latter scenario, does that head of product have experience outside of product management?
As noted before, engineers rarely report in to product managers, although it’s not impossible. Engineers also tend not to report up into product org hierarchies run by a product head, but again this is not unheard of. Still, there does seem to be a much greater willingness to subordinate UX and design “under” product than there does for engineering.
“It’s common to see UX reporting to Product (as well many other variations of reporting or independent areas) but surely if the company sees design as a strategic driver, then it should keep it out of the product report line to simply avoid “top-down effects” Caio B. Nishihara de Albuquerque, Design Lead @AmbevTech
If you go down the road of becoming a product manager and become a lead, you will eventually find yourself revisiting these questions: Is this your chance to finally make UX a full peer discipline? Can you recruit a counterpart and devolve the team to them. Or by this time, as a product leader who “knows your UX” will you start to think maybe there’s nothing wrong with you keeping both of them in your portfolio? We’ll come back to this question in Chapter 11.
In the end, it behooves you to focus less on how the lines of reporting are officially structured (while of course this matters a great deal in the long run and particularly when being evaluated and compensated) and to focus more on the relationships with your adjacent colleagues. Does it really matter if you both report up to a product director or if one of you reports to a UX director and the other to a product director (both of whom report to the same VP, or if not both of whose VPs report to the same SVP, ad infinitum)?
When you’re not a designer anymore
One caveat about shifting from a UX career to a product career is adjusting your self image and accepting not so much that you are not a designer any more (feel free to design things in your spare time!) but that you are not the designer on the team anymore. Many a UX-rooted PM have fooled themselves into thinking that the UX folks they work with should welcome their design suggestions because, you know, “they’re also a UX designer.”
Except you’re not. You took a different job.
You’re entitled to opinions. You can even share suggestions and design ideas. But tread carefully! Just as a client may interpret a wireframe literally despite all your pains to make it clear that it’s not “the final design” so does a design “suggestion” from a product manager who fancies themselves to still be a designer come across as a little too fully baked or, worse yet, as a command.
When I have had to function as an art director in partnership with a UX designer or manager, I bend over backwards to speak in terms of the problem space and possible approaches and hang a lampshade on design sketches or examples if I need to use them to communicate to make it clear they are to illustrate a concept alone and not intended as solutions or user-interface suggestions.
Being a hybrid
If you consider transitioning over time from a UX practitioner to a product manager, or even if you just continue to work in a digital product context, you may find an opportunity at some point to take a dual role. This tends to happen at startups or on small new teams being incubated inside larger organizations. Both of those scenarios favor people with a wide range of skills and the flexibility to apply the right tool to the right problem for the right amount of time.
In scenarios like this you are still the designer and this might sound ideal but in reality it’s incredibly difficult, because these really are two separate jobs. Doing any two jobs at once is a lot of work, not to mention the overhead of constant context shifting and having to back up and refresh your working memory. Worse yet, you can’t have honest disagreements with a peer because you are both people. How do you sort out a really tricky question where one solution provides a better user experience at the cost of sacrificing a different product priority? You already know what you think. Challenging yourself is harder than it sounds.
Still, such roles are a golden opportunity to start establishing both disciplines in ways that are aligned and compatible with each other. If you succeed and your team scales up, you can prioritize bringing in a peer as soon as possible so that you can focus on the role that suits you best.
UX Superpowers Alert
Another perspective that crosses this same spectrum is service design. Kristen Ramirez, senior user experience designer at Procore Technologies puts it this way: “We don’t necessarily have all the tools. At the same time I’m coming from UX, I’m doing UX really well. I’m doing more research, I’m doing more service design. And I think there’s a crossover there too.
I need to understand a business process because I need to develop the application to support it. If I don’t understand what people are trying to do then I’m not going to make a very good application.
One of the sites that I worked on was the Uber developer site. All of their enterprise data needs to be accessible and people need to know how to get to it. There were a lot of moving parts with that! It wasn’t just “how does someone do this” which is one of the things, but really “how do all these objects relate to each other?”
Coming from a design background, trying to speak technology to a developer, there’s a lot you have to learn that you’re not going to be able to learn just by talking to someone.
You need to kind of be able to model it, to really say, “I don’t think I totally understand these bits. Let me try to draw something for you to, to show these relationships.”That’s what I’m always about: Trying to pick up the languages of other people that I work with.
I’ve done a little bit of development in my past, front end. Not anything compared to the front end these days, but that still does wonders for working with the development team. I know that this is going to be weird or this is gonna be hard, or I’m going to have to ask questions about this thing. I think it’s the same for business. That was where service design was able to give me that bridge.
It’s really an operations problem, although the design is hopefully part of the solution. If you don’t understand the whole ecosystem, you’re going to pigeonhole your design.
Superfriends
I hope it doesn’t sound naïve to suggest that we are on the verge of an incredible blossoming of product / experience collaboration. The two concerns are so closely joined together and with a modicum of coordination and communication — two things that both product managers and UX people always claim to be good at — there’s no reason why they can’t be flowing together in a high-performance dance that multiplies each others impact in an ever compounding cycle of user-obsessed awesomeness.
Key Insights
- There’s no one answer to where you draw the line between product and UX.
- Nonetheless, each team does need to do the work required to draw these lines.
- Lines don’t prevent collaboration but they clarify who decides what.
- Well run product teams work through potential conflicts and establish well understood agreements about who is responsible for what.
- In a toxic product environment you need to pick your battles, document goals and metrics, and look for points of leverage (while planning your exit strategy).
- UX may report to product but this doesn’t really change the communication and collaborative effort required to achieve alignment.
- A product manager with a UX background is not a UX designer and shouldn’t pretend to still be one.
- Hybrids are both product managers and UX practitioners. This sounds like a dream gig but it’s more of a frankenjob.
- There’s really no reason why product and UX folks can’t soar together.
—
You can sign up to be notified when Product Management for UX People is available for order at Rosenfeld Media.
