Jeff Zych

Product Manager and Product Designer: Who Does What?

I recently noticed that my team of Product Designers at LaunchDarkly (p.s. I’m hiring) was having trouble navigating the overlap of Product Design and Product Management. No one said it explicitly, but after hearing some frustrations in 1:1s and team meetings I connected the dots that this issue was the common variable across a variety of complaints.

I was hearing things like, “I’m supposed to own the user experience, but the PM keeps cutting scope from my designs!” And, “Am I expected to run team whiteboarding sessions?” There was also confusion around the fact that sometimes they do customer interviews, and other times PMs do.

Product Managers also had some struggles with navigating this gray area. They want to shape the final product (as they should), but were unsure how best to provide input without stepping on the toes of designers. If I sketch out my ideas, am I doing the designer’s job for them? Is it ok to ask designers to do customer outreach and development? If the designs I’m seeing are missing the mark, how do I give that feedback without telling them their work stinks?

To clarify expectations for both sides, I wrote the doc below. It doesn’t try to draw a distinct line between the two roles, but instead explicitly states the area of overlap and provides guidance on how to navigate it. I also give advice for leaning on each other, such as asking PMs for scope, or asking designers for more iterations.

So far this doc has alleviated some confusion on both sides, and empowered my team to speak up when they need more from their peers.

If you or your team is struggling with this as well, I hope this doc will help.


The roles of Product Designer and Product Manager have a significant amount of overlap (they both have “product” in their title, after all). So who does what? Having overlap and redundancy is healthy and makes sure multiple people are thinking about the big picture. But fuzzy roles and unclear decision makers leads to people spinning their wheels and unproductive power struggles. This doc aims to clarify who does what by explicitly laying out roles, the overlap, and how to navigate the ambiguity.

Venn diagram of the overlap between Product Managers and Product Designers

Product Designers

Product Designers are responsible for creating great user experiences. What does that mean, though? Don’t we all own the user experience? In a sense, yes – everything the triad does will impact the final experience. Sales, support, and marketing all impact the customer’s experience, too. But in the context of the triad, the designer should be pushing for the best experience that meets business and customer goals, with the project constraints (scope, technical tradeoffs, what’s available in the design system, and so on). If the proposed design doesn’t meet the customer’s needs, or is hard to use, or unpolished, or doesn’t follow our patterns, that’s on the designer. They do this by owning:

  • Final visual design
  • Interaction design
  • Prototyping
  • Usability testing
  • Personas
  • Journey mapping
  • And more, this list isn’t exhaustive

Product Managers

Product Managers are accountable for the business value of their team’s output. If a project isn’t valuable to customers or LaunchDarkly, has unclear or incorrect scope, fuzzy use cases, takes too long to build relative to the value, or the team doesn’t understand what problem they’re solving or why, that’s on the PM. They do this by owning:

  • Roadmap prioritization
  • Team goals & strategy
  • Project scope
  • Project goals and success criteria
  • Data analysis
  • And more, this list isn’t exhaustive

The overlap

This still leaves a healthy amount of overlap between the two roles. Both do:

  • User research
  • User scenarios
  • Use cases
  • Lo-fi sketching and flows
  • Team workshops & whiteboarding
  • And even more, this list isn’t exhaustive, either

So who owns these activities? The answer is both. The best projects will have designers and PMs collaborating on these. But sometimes a designer takes the lead on research, or the PM will lead whiteboarding activities. It will depend on who has the time, skills, and interest, among other factors. When things are unclear, they should discuss who is doing what.

Additionally, being accountable for an outcome doesn’t mean you’re on the hook for doing all the work to achieve it. Nor does it mean you can’t contribute to what someone else is accountable for. Designers should contribute to use cases and scope. Engineers and PMs should contribute design ideas. Everyone should contribute to the roadmap. But at the end of the day, the person accountable for the final result has final decision making power.

Even so, this won’t prevent disagreements. You may not agree with the final scope, technical architecture, or user flows. Voice your concerns, have a healthy (but respectful) debate about the tradeoffs, and try to reach consensus or a set of next steps to resolve the tension. But at the end of the day, recognize who is accountable for the outcome, and thus the final decision maker, and disagree and commit.

Lean on each other

Knowing who’s accountable for what gives you someone to lean on when things are ambiguous. Use this to your advantage.

For Product Designers

  • Lean on your PM if you don’t understand the project’s goals, use cases, scope, or value. You can and should have an opinion on these, and shape them with your work, but it’s a fool’s errand to try to finalize a design if these aren’t crisp.
  • If you’re not sure about the technical tradeoffs of your design decisions, lean on your engineering counterpart.
  • If the PM or engineers have an idea for a solution, listen to it and make it real, even if you’re not sure it will work. Design’s super power is giving form to abstract ideas. Discussing a cheap throwaway mockup you’ve made can shortcut weeks of debate. I wrote a longer article about this.
  • You are expected to push for shipping the best user experience you can. Sometimes this increases the scope of a project. Sometimes this increases the technical complexity. You should discuss tradeoffs with your triad and reach consensus together. Don’t assume what’s easy or hard. Then make the best damn designs you can within the scope and constraints agreed upon.
  • Scope, use cases, and goals can and will change as projects move through discovery. Seeing real designs and getting user feedback changes your understanding of the opportunity space, so you should update the product spec accordingly.

For Product Managers

  • Lean on designers to help you with scope and use case decisions by cheaply exploring ideas together.
  • If you have an idea for a solution, get it out of your head and share it with your designer. But acknowledge it’s just an idea and the designer owns the final designs.
  • You see an area of opportunity that needs more research but don’t have time, ask your designer if they can lead customer calls.
  • If the solutions the designer is proposing are missing the mark, ask them to explore more ideas. Or whiteboard together if you’re seeing paths the designer’s not going down. You don’t need to be an expert in design and pinpoint exactly what isn’t working, but you can always ask for more options.

Create greatness together

Tension and overlap is healthy when roles and expectations are clear. This doc is a starting point and guide, but it takes practice to successfully navigate points of conflict. But when done right, you’ll ship solutions better than you would have alone.


Sound like the type of team you want to work on? I’m hiring.

Previous article « Learning the True Power of Artist Dates
Next article Books Read 2020 »