Product Managers Don't Own the Problem (And Designers Don't Own the Solution)

Imagine a product team discussing new commenting functionality on their company blog.

“We should let people comment anonymously.”

“That will only attract trolls. We should require real names.”

“We should require unique names, but allow pseudonyms.”

You won’t find a shortage of debate on this topic across the Internet. But there is no right answer.

Like many product questions, it depends.

It depends on your business goals. It depends on your audience. And it depends on the problem you are solving for them.

Businesses are good at taking care of their own needs. Some are getting better at understanding the audiences they serve. But few take the time to define the problem they are solving for that audience.

If your blog is for a well-connected, private community that relies on the comments to engage in civil discussion about topics that matter to them, then real names might be the most appropriate.

If instead your blog is for cancer-survivors who often share personal stories in the comments, pseudonyms may be a way for people to forge strong virtual connections without giving up their real-world privacy.

And finally, if your blog is about embarrassing personal topics that even pseudonyms won’t help people feel comfortable asking about, then maybe anonymity is your best option.

Each of these examples, represents a different problem for a unique audience.

Get Clear on What Problem You Are Solving

Take a minute to review your backlog. What do you find there? Is it full of solutions?

Many of us start with solutions.

But it’s also why you spend more time than you’d like arguing with people about which solution is better.

As we saw in the example above, it’s hard to evaluate solutions without having a clear idea of what the problem or opportunity is.

Understanding the nature of the problem helps us to understand just how good any particular solution is.

We need to spend as much time thinking about the problem as we do thinking about solutions.

The Role of Product Management and Design

As teams specialize, responsibilities are being split between product management and user experience design.

A common division of labor is for product managers to own the problem definition and for user experience designers to own the solution.

You may be working in a similar configuration today.

Product managers prioritize and define problems or opportunities by writing user stories or job stories.

User experience designers take that problem or opportunity and design the optimal solution.

But this is too simple.

If you read those last few paragraphs again, you might notice that they sound an awful lot like waterfall approaches.

The product managers starts the work and then hands it off to a designer who completes the work.

Not only is this not how true teams work, it doesn’t lead to the best outcomes.

Problem and Solution Definition Move Together

There has been decades of research across many disciplines on how design problems are solved.

Without exception, every model (see here and here for two examples) defines a two-way feedback loop between how the problem is defined and how solutions are generated.

How we define the problem impacts the range of solutions that are available. And as we explore solutions, we further refine the definition of the problem.

You’ve probably experienced this yourself.

Suppose like in the example above you are working on a comment feature. You have an idea in your head about how it might work. But as you sketch it out on a whiteboard, you start to uncover new elements of the problem.

Maybe you hadn’t considered threads. Or maybe you aren’t quite sure how to handle avatars when users are anonymous.

As you explore a potential solution, new constraints pop in your head. The problem shifts and morphs.

With each solution you consider, you start to get a better idea of the nature of the problem.

If you split problem definition and solution generation into two different steps performed by two different people, you lose these valuable insights.

You sever the feedback loops.

The only reason why we split these activities into two steps in the first place is because we weren’t paying enough attention to defining the problem.

Do pay attention to problem definition.

Define Roles That Make Sense For Your Team

Don’t draw artificial boundaries between product management and user experience design.

I’ve done both roles. The line is hazy at best.

Product managers may have deeper expertise about the market or the business needs, but a good user experience designer also needs to understand this context.

User experience designers may have deeper expertise about how to translate users’ needs into user interface components or compelling workflows, but a good product manager needs to have some level of competency in this as well.

Do specialize. But focus more on who does what and less on who owns what.

Both the product manager and the user experience designer need to own the product. Both need to feel responsible for the final outcome.

The product manager might spend more time supporting sales calls and communicating with executives. The user experience designer might spend more time working on wireframes and iterating on mockups.

But they both need to understand the problem they are solving and have input into what the final solution is.

And they both need to be engaged as the problem morphs and evolves as they explore different solutions.

Stop Relying on Authority to Make Decisions

Where most teams run into problems is deciding who gets to make which decisions.

Product managers and user experience designers often collide when they disagree about a workflow, a user need, or a release date.

Too quickly, teams rely on authority to win these battles.

The product manager in a rush to make a release deadline ignores the designer’s concern that the new feature doesn’t match the style guide.

The designer refuses to adjust a call-to-action that isn’t consistent with the product messaging over concerns that the product messaging isn’t clear enough.

You’ve probably experienced similar battles.

In an ideal world, the product manager and the user experience designer should agree. You won’t always be able to get there. But you should try.

The key is in the trying.

Rather than arguing over two outcomes where only one party is happy, both should work together to identify a third outcome that satisfies both parties.

How might we meet the criteria of the style guide and still make the release deadline?

How might we change the call-to-action so that it is both clear and consistent with the product messaging?

Both the product manager and the user experience designer should be expanding the options rather than arguing for the choice that only meets their own needs.

Do the Work Required to Collaborate

The only way to generate options that satisfy both parties is for each person to do the work to understand what their own problem is.

But you can’t satisfy a need without understanding what the need is.

A savvy reader might realize that we’ve come full circle.

We started with understanding a user problem. As you explore and evaluate solutions, you need to match the solution with the current problem definition to understand whether or not it satisfies the users' need.

If you encounter conflict amongst your team along the way, each of you needs to do the work to understand the nature of the problem you are experiencing so that you might together find solutions that satisfy each of your needs.

This process is iterative. The more that you can view your teammates as users that also need to be satisfied with the solution, the more likely you’ll find a solution that meets the team’s needs.

Don’t Wait For Conflict to Arise

In the heat of conflict it can be hard to collaborate. Take the time now to define how you will handle such conflicts before they arise.

Here are some questions to consider with your team:

• How will you ensure that your team spends as much time defining the problem as they do generating solutions?
• How can you ensure that the product manager and the user experience designer are engaged in both defining the problem and generating solutions?
• How will you divide up the necessary tasks in such a way that doesn’t sever the feedback loops between defining the problem and generating the solutions?
• Do each of you commit to doing the work required to collaborate - working to understand the nature of your own problem when conflict arises?
• How might you remind each other to consider new options rather than arguing over options that don’t satisfy the team’s needs?

Capture your answers in your team charter and make sure you revisit it on a regular basis.