Who has the final say: UX or PM? (Hint: you’re missing the point)
By: Jake Carter
Tags: Team Collaboration, User Experience, Product Management, Resources, Technology

What’s the solution?

I don’t think we should accept this as the status quo. The good news is, it doesn’t have to be. By and large, I‘ve avoided almost all of these problems, and I believe that by following two proven principles you can too.

(1) Common Goals and (2) Communication

Yeah, it’s kind of that easy. But don’t think I’ve presented these here as empty platitudes, let me explain how you can actually leverage these.

But first, let’s get this out of the way: does UX or PM have the final say in product decisions? Simply: it doesn’t matter.

This is the wrong question. It’s a distraction. An immature inquiry to settle petty squabbles. It wrongly assumes that any one role is equipped with the definitively correct answers.

“The data should win!”, you say. Sure, I believe that is generally true, but data is too easily tainted by interpretation. Especially in discovery stages. Sometimes you just have to make a decision, ship it, and see how it performs.

So, it’s NOT about answering this question and more about having a common understanding of where we want to be as a team and then doing our best to get there together.

Common Goals

What should a product team’s common goal be? Easy: the business must win.

It’s almost that simple. All internal disagreements aside, the company for which you are building products must succeed. It’s futile to argue if UX or PM wins if the company loses.

A close second is: the team must deliver.

Only team’s that deliver value can justify their existence. If a team isn’t contributing value, it’s simply a liability.

Further, it’s not just one discipline that is responsible for delivering value, it rests on the shoulders of the whole team! Even if one role is performing perfectly, it still takes the rest of the team for that person to actually deliver value to the business.

So what do you do when two members of the team have strongly held opposing views? It may seem a simplistic answer, but there really is no other way: give and take.

“But what about the user?!”, a Designer cries. “What about our business needs?!”, a Product Manager wails.

Look, you’re both smart people. Your organization is trusting you to do what is best. So do your best. Together.

This is where the give and take comes in. The truth is, many products launch with less-than-ideal user experiences and the world hasn’t ended. Sometimes a product is behind schedule or may not have every feature you’d like and somehow the company goes on. It’s up to each role to make concessions where it can. Give here, take there. And if you are both doing it with the common goal of winning, everything will be fine.

Remember: a team is only as good as what it delivers together.

A product with great UX is worthless if it never makes it to market.

A product shipped on time might be full of bugs.

A product with elegant code may fail to generate revenue.

If you want to utilize the principle of Common Goals on your product team, keep these things in mind:

The best product is usually a released product!

product! Defer to the domain expert when feasible, but focus on team wins.

There’s more than one acceptable way to build a product, find one that helps the company win.

Communication

Having common goals points to where you want to go; communication is how you get there. We’ve already established that we have the same goal, this principle is about communicating in such a way that the team actually gets there.

I’m not going to wax-poetic on this one, let’s just get to it:

The Designer and Product Manager should be involved in all discovery efforts.

This is just good practice. Do it, you’ll thank me. People see the same things differently and having an extra set of eyes on the problem will pay dividends. You need more than one subject matter expert and nothing beats first-hand knowledge. As a PM or UX, don’t think that you can just explain things after the fact. It’s harder, takes more time, and is less reliable.

Even when you are in the same discovery sessions it’s helpful to have post-discovery debriefs to check for converging/diverging interpretations on what you just observed. Once you check for understanding you can decide on next steps and get to work.

This applies to face-to-face discovery sessions and even short one-liner chat questions (just make it a group chat). If one of you discovers something asynchronously, do your best to let the other know what you learned.

This is key: if this type of communication and collaboration is happening in discovery it’s very likely that you can (and you should) extend this to all other aspects of the product lifecycle: design, testing, grooming, and even development. PMs if you hear something about business strategy let your designer know. UXers, if you have a few design ideas you are considering, get them in front of your PM. If there is a clarifying question from development about requirements, discuss it together.

Learn to rely on your team-mate’s help and expertise. I’ve never regretted being fully integrated with a Product Manager. I’ve lost track of how many times I’ve had to rely on my PM’s memory to answer tough questions.