Should product managers come up with solutions, or only define problems?

This is a co-authored blog post with my friend and fellow product manager Nikta Kanuka, who has published it on her blog.

The product manager role varies from one organization to the next. At some companies, in addition to identifying user and business problems, PM’s are expected to come up with solutions to those problems (or they take this task upon themselves). In other companies, this function lies squarely within the UX team’s ownership.

So — should PMs solely define problems? Or also solve those problems? Or perhaps we should ask: to what degree should PMs solve user and business problems?

Defining problems is a full time job

All PMs need to define and prioritize user and business problems. Alongside communication, this is our principal responsibility.

Done well, this is a full-time job requiring:

• User research
• Analytics
• Identifying high-impact business levers
• Competitive and comparables research
• Identifying market opportunities
• Communicating distilled insights to designers and engineers
• Facilitating product delivery and creating team mo-jo
• Meeting the needs of the entire company — marketing, sales, support, ops, research, data science, executives — the whole shebang

Designers need the freedom and trust to absorb that understanding to produce a solution that works within the boundaries of the problem space. If your designer pleas, “Come to me with problems, not solutions!” then check yourself (before you wreck your designer!).

But every PM at some point has proposed a solution to the designer. It’s natural. Sometimes it feels necessary for velocity. Sometimes a PM needs to probe solutions to better understand the problem itself. Some PMs just communicate via wireframes.

Understandably, designers can get frustrated when they believe PMs overstep their boundaries. Fair enough. The PM and UX roles are separate for a reason. Much like backseat driving, simply telling the designer what to ‘make pretty’ rarely produces the desired outcome.

Stock image of backseat driving.

While PMs can produce bad designs at times, some PMs have nonetheless designed iconic products or features that generate billions in revenue. There has to be room for PMs to contribute big ideas, while also allowing designers the creative space to do their best work.

When designers don’t design, it can hurt. (Note: the red arrow is part of the website, not added afterwards.)

Pinterest’s first Pin. CEO Ben Silbermann had product experience, but no formal design training. Yet he designed the iconic Pin action and grid layout. Source: Business Insider

So –– should product managers come up with solutions, or only define problems?

Annoyingly, our answer is that it depends. We believe the three principal factors are:

1. What is the purpose of the team? The more experimental, the more PMs will be involved in solving problems.
2. What are the scarce skills on the team? Lower UX capacity requires more PM problem solving.
3. What’s the PM’s personality and skill set? More creative and collaborative PMs tend to fare better when solving problems.

1. What is the purpose of the team?

For a moment, let’s boil product management down to just discovery (what to build) and delivery (building it). We parallel track these, but at any given time, one is more important than the other. Riskier products need more discovery focus, and more clearly defined products more delivery.

Rapid experimentation is the best way to discover the right product and invalidate good ideas that happen not to work. The problem is: we need to invalidate those ideas upfront, not in production (even though production data has the highest quality signal).

PMs and designers work under the constraint of delivering a small number of high quality, validated features quickly. That means most experiments must occur in the design and no-code prototyping phase. That process is faster when the PM plays a part prototyping, testing, and iterating.

So if discovery is the priority, and the team must experiment quickly, the PM should play a greater role in solving user problems.

Examples of team goals where PMs should be more involved in discovery and solutioning:

• Finding product-market fit (pre-seed & seed companies)
• Finding product-market fit in a new market segment (ex. Airbnb Experiences)
• Attaching new revenue to existing segments (ex. Shopify shipping, or insurance; Opendoor Home Loans)

Examples where PMs should focus more on delivery:

• Scaling (Series A, B)
• Maintaining market dominance (established company)
• Implementing a go-to-market strategy (ex. Zillow monetizing the Zestimate)
• Well defined, but technically complex products (this leans into program management or technical product management)

2. What are the scarce skills on the team?

This is a simple one — product managers should prioritize their time given skillsets of others on the team.

PMs should be flexible enough to fill gaps. If a UI designer isn’t as comfortable in or simply doesn’t want to do UX work, the PM should step up there. After all, we already have a deep understanding of user needs, stakeholder needs, and comparable products — so we are well-positioned to do so.

On the other hand, if the design team is well-equipped, then PMs might play a diminished role in solutioning. For example, product designers lead solutioning at Apple (or so we hear).

Even with an excellent UX designer, solving user problems is rarely the prerogative of a single individual. Although the designer is responsible for the UX and UI, everyone on the team should feel free to propose solutions, from support agents to marketers to engineers.

3. What’s the PM’s personality and skill set?

Everyone with a pair of eyes thinks they’re a designer. We have sat in countless meetings where each participant gives their opinion on interaction patterns, information hierarchies, or even the style of a button (often “bigger and bright red!”).

While few of us have design training, any one of us can practice design thinking — ethnographic research, reframing problems, experimentation, using diverse teams, and so on.

The question is: are you a design thinker?

• Designers take a beginner’s mind — they listen, observe, and validate assumptions. They don’t presume to know the best way to achieve an outcome upfront.
• Designers take good ideas from everywhere — they’re collaborative, open communication to get the best ideas from others, and integrate diverse ideas into a unified concept.
• Designers are creative — they explore concepts, twist rules, and fearlessly experiment with things nobody else is talking about. They do simply apply conventional solutions.

Here’s an example: suppose our users complain that they cannot find an item they are looking for in a list. Some basic solutions spring to the PM’s mind:

1. Build a filter to allow the user to see a subset of the list (easy to scan)
2. Build a search box and hope the user remembers some narrowing keywords
3. Build a sort function to put some items at the top (easy to locate)
4. Build a system that hides items that are no longer useful (easy to scan)

If you’re not yet a design thinker, you might just open Jira and type this story:

As a user, I want to be able to filter by file type when I am searching for my file on this list, and the filter button should be in the nav bar.

That’s exactly what some PMs do. This can cause all sorts of unintended negative effects, like poor UX, deepening issues in the overall system design, creating yet more custom components that make engineers shudder — or worse yet, not actually solving the problem.

Rather, the PM should write a brief for the designer like:

As a user, I want to find files in fewer than 5 seconds.

This brief leaves room for designers to explore creative solutions. (In this example, we’ve both seen great solutions that don’t even include a list anymore!) You might think the right solution is a forgone conclusion. But often there are better solutions just around the corner — design thinking can push you there.

Summary

PM’s should focus on understanding user/business problems, prioritizing this list, defining the boundary of the solution space, and defining success. We should trust our designers and engineers to build the solutions while we guide and facilitate.

PM’s should never stay completely away from product design solutions because we are ultimately responsible for the success of the product delivered. Designers create magic, but they’re not magical people. Anyone can get better at designing — and PMs are especially well-positioned to do so.

PM’s should solution more if:

• The hard part of the problem is discovery (what to build) — i.e. the rate of experimentation
• The scarce skills and capacity are in problem solving
• If they’re good at it (beginner’s mind, collaborative, creative)

PM’s should solution less if

• The hard part of the problem is delivery
• The UX team is mature and has plenty of capacity and creative space
• They aren’t good at it (conventional, prone to but big red buttons with exclamation marks on the page)