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

Teresa Torres argues that product managers and designers should not split the work cleanly into 'PM defines the problem, designer owns the solution.' Problem definition and solution generation form a two-way feedback loop, and handing them off sequentially severs the insights that emerge when exploring solutions. She suggests focusing on who does what rather than who owns what, and resolving conflicts by searching for a third option that satisfies both parties instead of relying on authority. The piece matters because it reframes collaboration between PM and design as a shared, iterative effort around understanding the problem.

01Key takeaways

• Spend as much time defining the problem as you do generating solutions.
• Be wary of starting from a backlog full of solutions without a clear problem statement.
• Avoid splitting problem definition and solution design into sequential handoffs between two people.
• Focus on who does what rather than who owns what, while both roles share responsibility for the outcome.
• When PM and design disagree, look for a third option that meets both constraints instead of deferring to authority.
• Agree on collaboration and conflict norms with your team before tensions arise and revisit them regularly.

02Key sections

Problem before solution

Teams often start from solutions, but the right answer depends on the business goals, the audience, and the specific problem being solved. Using a commenting feature as an example, the author shows that the same question yields different answers for different audiences.

Splitting PM and design roles

A common division has PMs defining problems through user stories and designers owning solutions. Torres points out this resembles a waterfall handoff that does not produce the best outcomes.

Problem and solution evolve together

Design research across disciplines shows a feedback loop between defining the problem and generating solutions. Sketching a solution surfaces new constraints, so separating the two steps loses valuable learning.

Shared ownership and authority

Rather than drawing hard lines, both roles should own the product and understand the problem, with specialization in focus but not in ownership. When conflicts arise, teams should seek a third option that satisfies both sides instead of using authority to decide.

Agreeing on conflict norms

The author recommends defining in advance how the team will handle problem definition, collaboration, and conflict, and recording those agreements in a team charter. These norms help keep feedback loops intact under pressure.

03From the post

“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.”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.