What Should Designers Expect from PMs? Part 2

Q: I argue with my PM 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 mockup factory. Is this kind of “healthy tension” normal between designers and PMs?

At a high level, the Product Manager is meant to help steer a team towards a successful outcome. When PMs do their job well, the team sets realistic and inspiring goals to build great products for people, and then hits those goals.

Last week (in Part 1 of this post) I shared a few things that can happen in the Designer-PM relationship that are okay/normal, including:

• You find you and your PM have overlapping skills.
• Your PM isn’t driving the product vision.
• Your PM doesn’t have a developed design eye and tends to be more focused on the team’s metrics.
• Your PM doesn’t have much prior experience working with designers.
• You and your PM disagree on stuff, maybe even a lot of stuff.

Here is another common situation that warrants its own bullet point:

You can’t figure out how to resolve whether to pursue a “full vision” experience that takes a long time to implement, or whether to launch something quickly and then iterate.

The concern that designers have is two-fold: (1) if a problem is framed as “we need to ship something in 3 months,” that framing limits the types of ideas that can be explored, and may mean we are not actually be solving for the best long-term solution (2) if we take shortcuts and build out something quickly, the result may not be high-quality enough to work in the market (because it’s sloppy and doesn’t make a good first impression, because the feature set has been so pared down as to not have a clear narrative around why people should like and use this, etc.) Meanwhile, a PM’s concern in this scenario is that in order to build the “full vision,” it could take a full year or more, and if our solution isn’t the right one, then we will have wasted a year before we realize that it wasn’t the right path.

Three things you should figure out here:

1. Are you aligned on what problem you want to solve? If not, then get to alignment before discussing solutions
2. Can you align on what matters most — getting to the best 1-year-out solution, or getting something reasonable out to start learning in 3 months? If it is the former, then you should bring up needing 2 or 3 weeks to explore the broad range of solutions (and potentially do a sprint with your team) to get to a clearer point of view. In some cases, like the when there is a hard launch deadline, doing something quickly may matter more than doing something in the long-term optimum way. If you must ship something quickly, then clearly separately two streams of work — a workstream that gets us to the best thing we can do in 3 months, and a workstream that still lets the team explore and get to the best thing in 1 year. By talking about these as two separate problems and workstreams, you can then start to figure out how to carve out some time to do the longer-term exploration.
3. Now assuming you have a clear long-term design/product vision — ask what is the minimal set of changes we can roll out that would solve the problem? If your intuition does not align with your PM, see if you can set up some research or data questions that would give the team more signal.

Things that can happen that you should take action on…

When things aren’t going well, you should take action.

Note: “taking action” does not mean assuming ill intent or passing negative judgement on a person’s abilities. At the end of the day, everyone on the team wants the same thing — for us to build great products for people. And each of us has a responsibility to try and make that happen by identifying and acknowledging when things could be improved, and then figuring out the next step. See the section below on specific “actions to take.”

Issues involving Product Sense

• You or other folks on your team can’t clearly articulate what problem you’re solving for people, how we know it’s an important problem, and what the outcome would be in the world if you were successful (instead, you may spend all your time discussing the tactics of specific projects.)
• Your team has a roadmap that doesn’t actually address or tackle the biggest problems you’ve identified (for example, you have 50% of the team working on problem A when Problem A is less important than problems B, C, or D)
• You don’t understand why your PM is asking you to design something (because it feels unimportant, because the idea doesn’t make sense, because it’s not clear what we would do with the results of this experiment, etc.)
• Your team doesn’t have a shared picture of what a high quality standard for the end result is, leading to shipped products that you or other folks across the company feel are poorly crafted.

Issues involving Execution

• Your team spends a lot of time talking about new ideas, but can’t prioritize those ideas or turn them into concrete plans that people can make progress on.
• Your team doesn’t set clear milestones or expectations for the next few weeks/months, so there isn’t a sense of clear direction or urgency for when things should get done.
• Your team has a pattern of setting milestones (on things like design complete, eng compete, when test will go out, etc.) but regularly misses hitting those milestones. (For example, your team will say things like “we’re about 4 weeks until a full launch” for the 3+ months due to unexpected delays, test results, etc.)
• Your team doesn’t look for shortcuts to get to lessons and validating hypotheses quickly. Mistakes in this camp include: (1) not considering if there are shortcuts to testing a hypothesis (for example, validating with research, building a quick prototype to test out how it feels before committing to production-level scale, etc.) (2) building a product or testing out a hypotheses on two platforms simultaneously without understanding if the core people problem or hypotheses are sound (3) trying to roll 10 ideas into one mega-change rather than splitting stuff up into the smallest building blocks to move quicker and get more certainty on validating each idea. (4) building something another team has attempted in the past without a clear understanding of what’s different about your proposal this time around
• You end up looking back on your project and wondering “why has this taken so long?” Usually when you feel this way, it’s a sign your team has not executed very well.
• At the end of a project (whether it’s successful or not), your team doesn’t do a good job understanding the lessons learned, and what things you would have done differently if they could do it again.

Issues involving Team/Leadership/Drive

• Your PM says or behaves in a manner that makes you feel undervalued, or like you are a resource rather than a partner who is invested in building a great product. Examples of this are: (1) asking you to make a design change or make something look good but not giving you context on the problem. (2) asking you to create a mock of something the PM has in her mind without asking you to weigh in on the solution. (3) not including you in team discussions around goals, strategy or roadmap for the project (4) presenting your design work in meetings/reviews rather than encouraging you to do it.
• Your PM behaves like a “mini-CEO” where they are acting as if they can tell everyone what to do instead of bringing the team together to discuss important topics, leveraging the individual strengths of those on the team, and creating a shared, collaborative environment to work.
• You find yourself in too many meetings such that you have little time to actually do design work. Ask yourself: “Are there ways my PM can help me focus more of my time on design work?” and “can meetings I need to be in be better structured to take up less of my time?”
• You feel like you are frequently left off of team communication that would give you important context to help you better do your job (for example, your PM doesn’t share relevant data or research with you, or give you context on feedback they heard while you weren’t there, or doesn’t invite you to a review where your work will be discussed, etc.)
• Your PM says things or does things to you or others on the team that feel rude or immature. Facebook in general does not tolerate assholes, and the bar for maturity and good communication is higher for PMs than for most other functions.
• When you raise issues or suggestions around how the team could do better work or work better together, you get the sense it isn’t welcome (the PM responds defensively, downplays your concerns, doesn’t listen or give you the time of day, etc.)

If I spot an issue, how should I take action with my PM?

There are three things you can do:

• Give feedback directly to your PM. This is the most recommended course of action because it speaks to the values of being direct and honest, even if it means having a hard conversation with someone. I find this to be the most effective way to build a trusting, long-term relationship. If you are unsure of how to do this successfully, there are many resources to help, including the excellent book on Crucial Conversations.
• Discussing how you feel with your manager. Your manager can do a few things: listen, share additional context or perspective that helps you understand whether the behavior you are seeing is normal or not, and advise you on how to best proceed (either coaching you on how to have the conversation with your PM, or your manager having this conversation directly).
• (In some instances) sharing the feedback with your PM’s manager: Before you do this, please discuss this with your own manager first. While this may be appropriate in certain instances, we don’t want to create a culture of giving critical feedback behind each other’s back because it feels inefficient, less effective, and makes people wary of whether their colleagues are being real with them.