What Should Designers Expect from their PMs?

Q: I argue with my product manager all the time. He works well with everyone else on the team, and the engineers and analysts all like him. But sometimes I think he doesn’t care about design, and he treats me like an on-demand mock up factory. Is this kind of “healthy tension” normal between designers and PMs?

This is a great question, and I just so happened to have written about this very topic a while back for my own team!

One of the hardest things to get a handle on when you start at a company is understanding what the norms of the company are. When something happens that feels a bit off to you, your first instinct is to wonder, “So X happened… is that normal?”

This question is especially salient in the PM-designer relationship, which tends to be critical to product success and personal job satisfaction. And yet, unlike design or engineering where the role feels easier to understand (if a product is buggy or slow, everyone knows that’s an engineering issue; if a flow is confusing or looks bad, everyone knows that’s on design), the PM role is more ambiguous, not to mention varied. Add to that the fact that most designers haven’t experienced working with many different PMs in their career, and you get lots of questions along the lines of “what is the most effective way to work with my PM?”

Remember that this relationship goes both ways — you are there to help your team and your PM, and your PM is also there to do the same thing for you. It’s my hope that the below helps you have a clearer sense of what to expect in working with your PM, and how to hold you and your PM to a high bar for a productive relationship.

What does a PM do?

At the highest level, a PM is meant to help steer a team towards a successful outcome. They are held responsible for that outcome. That means if the team sets realistic and inspiring goals to build great products for people, and then hits those goals, then the PM has done a good job. If not, then they haven’t.

At the same time, a PM has no explicit authority to tell anybody what to do (they are not the managers of the engineers or the designers; they can’t hire or fire people). So they must get these things done through rallying the team towards a shared goal or mission, communicating and project managing effectively, and generally being someone people trust and want to work with.

A good PM will identify what’s getting in the way of the team being able to succeed, and then work to fix those things. Because of the explicit nature of the ownership of PMs, they often tend to be the natural point of contact when someone (another team, leadership, etc.) raises an issue or wants to discuss something about the project (thus leaving engineers/designers to have more time to work on their craft and spend less time in meetings.)

Here are the 3 core skills we look for when interviewing PMs:

• Execution: “Can they clearly define success with clear objectives and get things done?”
• Leadership + Drive: “Can they build and support a team and make sure everyone has the information they need to do their job well?”
• Product Sense: “Can they proactively identify important problems to solve for people in support of company goals and build a compelling strategy to address those problems?”

As a designer, you should expect your PM to:

Drive execution:

• Make sure the team prioritizes effectively, sets good milestones, and hits those milestones.
• Breaks down an ambiguous problem into a clear plan of action
• Ask for commitments and remind team members of their commitments (for example, getting X done by Y date.)

Be an effective team leader:

• Fairly and honestly represent the entire team’s point of view in reviews, written summaries, and communication to other teams (and encourage other members of the team speak to their area of expertise.)
• Communicate transparently and succinctly in written and verbal communication.
• Lead discussions around (and provide context on) why what the team is doing matters, and what success looks like.
• Include, listen, and truly hear your (and the rest of the team’s) point of view on the goals, roadmaps, and criteria for success for the team.
• Be someone who is professional, mature, and respectful in their behavior
• Own being a point of communication with XFN partners (for instance, if the team needs to work with legal, policy, i18n, marketing, PR, etc — that coordination responsibility usually falls on the PM.)

Help create great products:

• Understand the business thoroughly, and balance needs on what people want, what publishers/advertisers want, and what the company needs in order to sustain the business
• Drive a compelling strategy and roadmap to address those problems
• Define a high quality standard for the resulting product
• Challenge you on design or product decisions in the interest of building the best thing for people.

Things that can happen that are okay/normal…

You find you and your PM have overlapping skills.

For example, you may both contribute ideas to product vision, or you may both have ideas about how the team should execute/prioritize/set goals. This is okay and actually expected, especially at more and more senior levels where all roles regardless of discipline basically converge because your scope grows to own more and more of the entire problem/product area/team rather than any one facet of the problem. The PM role may overlap with both the designer and design manager roles (typically more the latter.) They may also overlap with engineering managers and tech leads.

The best way to deal with a situation where you constantly find you and your PM trying to do the same things is to have an honest conversation about each person’s strengths and what division of responsibility leads to the best team outcome. It’s totally fine if after such a conversation, a designer or design manager writes and presents some review deck, or a PM comes up with a wireframe for a complex flow. There are teams where “product vision” or generative ideas come from design or engineering, and a good PM will recognize that and empower their teammates. There are also teams where the PM is clearly a stronger product visionary than the designer or engineers, and should be more influential in that respect. Don’t get too caught up on what the boundaries are between the roles. Don’t let your title define what you do. As long as you have an explicit conversation with your PM to get to a shared agreement, and you come at this from an angle of “what can each of us do that is best for the team?” then that is the principle that matters the most.

Your PM isn’t driving the product vision.

Related to the above, expecting every PM to be great at coming up with creative and compelling product visions is like expecting every designer to be an amazing visual designer. Some are, some aren’t, and that’s okay. If you aren’t amazing at it, you should choose projects where that’s less of a critical requirement, or you should rely on your team members who are much stronger in that dimension than you are to take more ownership and give you a ton of feedback.

PMs, even if they aren’t the most generative visionaries, should be good at making sure problems and solutions are well-framed, that ideas are supported or refuted with the appropriate research/data, and that the general plan isn’t crazy.

Your PM doesn’t have a developed design eye and tends to be more focused on the team’s metrics.

Again, this is okay. PMs should have generally good instincts on what is a clear flow versus a confusing flow, but shouldn’t all be held to the same expectations as designers. PMs usually make up for lack of intuitive eye by relying heavily on real data — research, analytics, test results, etc. which is positive as it helps the team get to the truth of how real people feel and behave.

That said, it’s possible anything we are measuring doesn’t tell the full story of an experience, or doesn’t do a good job predicting holistic or longer-term changes. Even if you suspect this may be the case, don’t frame the disagreements you and your PM have as “metrics versus a good experience” — because metrics should technically give us more clarity on whether we have a good experience or not. Instead, assume you and your PM are both trying to make the product decision that is in the best interest of people, and consider that you simply have a different perspective of how to interpret what “best interest” means. Ask yourself “what would convince me whether an experience was good or bad, and how can we look at research/data to help us know with greater certainty?” and use that as a jumping off point for understanding whether the metrics you’re looking at answer the right question.

Your PM doesn’t have much prior experience working with designers.

This can happen because PMs come from all different backgrounds and companies. Maybe at their last company, designers had a smaller-scoped role focused more around visuals. Or maybe at their last company they had wire-framers and visual designers and more specialized roles. Or maybe this is their first role PM-ing a more consumer-facing product.

If your PM says or does things that seem insensitive to understanding the kind of design we do here (like making a remark that treats design as a resource), assume best intentions and don’t get upset (unless it is a repeat offense where they’ve heard your feedback and are just ignoring you.) Simply have the conversation with them. Share some resources on how to work better together and help them see things from your perspective. Think of your job as educating them on what design is, and what value it can provide. Don’t be afraid to be explicit about how you’d like your PM to work with you and why you think doing things that way helps the team be more effective overall.

You and your PM disagree on stuff, maybe even a lot of stuff.

It’s expected that you and your PM should challenge each other and have different philosophies on things. Maybe your PM thinks your design, while innovative, is too complicated or isn’t worth the tradeoff it would take to build it. Maybe you point out that the team’s goals don’t seem people-oriented enough. This is okay. Disagreements tend to be healthy, and studies show that a team with diverse perspectives get better outcomes. You may disagree on things such as how important deadlines are, interpreting whether some data indicates a product decision is right or not, the importance of moving quickly versus getting focusing on craft, etc.

I won’t tell you there is a blanket “this is the right answer, this is the wrong answer” to these kinds of debates. The push-pull is what leads to the best results, and nobody is always right. The best thing you can do is develop a trusting relationship with your PM where you feel comfortable debating these issues and figuring out how to resolve or escalate them, keeping in mind “what’s best for this product and our team?” as the guiding principle, and being open and reflective in looking back and learning from what worked and what didn’t. Great PM-design relationships are not about 100% agreement, but about forging trust and mutual respect. To get to that level, you must respect your PM’s abilities, and vice versa. If mutual respect is not in place, then that is something you need to take action on.

‍