Photo by Christopher Wong

How to Work with PMs

A Cheat Sheet for Designers

Once, a long time ago, I was a product manager. Then, I was an engineer. For the past seven years, I’ve been in design. Every single day, I work with people in all of these roles. Every single day, I find new ways to appreciate the responsibilities, challenges, and art behind each of these three pillars of product development. The PM is a chameleon of sorts, constantly adapting to what is needed to ship a successful product. As a designer, how do you handle their affable charm and their data-gushing, team-herding, smooth-talking ways? Read on.

Understand that the PM’s job is to be a connector that helps teams ship successful products.

This means PMs are, for the most part, exceptionally good at:

1. Clear communication: as part of helping teams successfully ship great products, PMs need to represent the goals, priorities, and roadmap of a team to many constituents, including legal, marketing, customer operations, sales, and more. This means they need to be crystal clear, succinct, and on-topic. A designer or engineer with a tendency to ramble or mumble can be forgiven—it’s not usually the first thing in the job req, after all. But a PM who does the same will not last long. This is why PMs tend to represent the product to executives or to external press—it’s not because they’re considered more ‘elevated’ than design or engineering, but that PMs are on average better at communicating because they won’t get hired if they aren’t.
2. Being organized: in order to successfully ship great products, a PM must understand at every moment how the project is going, and whether it’s on-track or off. She should be able to deliver the entire map of all the pieces that are required to come together for something to go out the door. This requires ruthless, ninja-level organization skills.
3. Working well with a variety of people in a variety of roles: it’s not uncommon for a PM to talk with dozens of people across different teams throughout the course of a single day. Since PMs don’t typically have the authority to make something happen (they can’t directly hire or fire engineers or designers, for instance), they need to demonstrate and earn trust. If a PM is an asshole, it generally comes out rather quickly and cripples their effectiveness. Everybody knows the old cliches of the eccentric, curmudgeonly engineer and the unreliable, Don-Draper-esque designer, but I have a hard time coming up with a similar caricature for a career PM. Again, a pretty big generalization here, but I’d posit that on average, PMs have higher levels of maturity and empathy for others in the organization than engineers or designers.

At the same time, any specific PM, like any specific designer, will have their own unique set of strengths.

Being communicative, organized, and easy to work with isn’t enough. A good PM must also demonstrate some combination of the following skills:

1. Execution: how well does the PM ship products that are 1) successful relative to goals, 2) on-time relative to expectations, and 3) smooth relative to how the team feels about it? The more senior the PM, the bigger and more ambitious the project they’re expected to execute. (For instance, a junior PM may take on a project like add feature X to product Y whereas a senior PM may take on a project like build a new mobile app suite Z). Executing well is like captaining a tight, smooth-sailing ship. You need to make sure that everyone knows what they need to do and then does it, that the crew hums together in unison, that you estimated the journey well enough to have packed ample supplies, and that when you set out for X marks the spot on the map, you don’t end up at the sea monster instead (who will probably eat you all alive.)
2. Design thinking: how well does a PM understand, appreciate, and help drive a successful user experience? A PM with this strength will be one that designers clamor to work with. This isn’t to say that she has to be good at designing herself, but that she should have a critical eye for what is or isn’t a strong design proposal, and understand a designer’s values even if she doesn’t always agree with the suggestions.
3. Analytical ability: how well does a PM plan for and then draw conclusions from known inputs (quantitative data, tasks, user feedback, past experiences, etc) in order to craft a well-rationed plan for the future? An analytical PM considers all the ways something can be known and unknown, and figures out how to gain more certainty and predictability for the future. A strongly analytical PM will use all the tools at her disposal to figure out how to set goals, prioritize tasks, and sequence projects in a way that inspires confidence.
4. Product vision: how well does a PM read the market and current technologies, problems, and attitudes to come up with new and innovative solutions to problems? This is generally a more senior-level PM skill. PMs who are visionary are like a spark—they ignite and inspire entire teams of people to chase after bold, sometimes very risky new directions.

As a designer working with a PM, it’s important to keep in mind that the overall team must be well-balanced and well-suited to the task at hand. This means, for example, PMs who are weaker on design thinking should probably avoid heavily design-centric projects like redesigns or some major new user product, or be paired with senior designers who can help fill that skill gap. Similarly, designers who need more structure around goals and timelines may do well to have a strong executor PM to keep them focused on the most important things.

Your job will be easier if you treat your PM as a partner and a resource, not a taskmaster.

Need context on some related product area? Your PM’s got that. (And if they don’t, they’ll hook you up with somebody who does, or keep digging until they find the answer themselves.) Want feedback from customers, or salespeople, or your users? Your PM can make it happen. Want to know the current set of priorities or fires or what the worst-offender bugs are? How about what the latest data teaches us about Feature Y? Surely you’d appreciate some additional perspective on how to prioritize the 7 design ideas you just came up with and which ones you should explore first.

Your PM can arm you with context, with data, and with insightful feedback so that you can do your best and most impactful design work. Your PM can shield you from 85% of the distractions that’s going on around you so that you can focus on the work. Just don’t be afraid to ask.

You are going to disagree with your PM.

This is certainly going to happen. Most of the time it’s okay, it’s just the natural system of checks and balances between the three pillars of product development (product, design, and engineering). There are a few common ways this disagreement manifests:

1. Is this product good enough/ready to ship? Since PMs are responsible for getting products out the door successfully and on-time, they have a natural incentive to push for aggressive milestones so they can ship and then iterate quickly. Since designers are incentivized to produce the very best user experience they can, they prefer to have more time on the design, implementation and polish stages. Taken to the extreme, neither of these are reasonable positions. Nobody wants to ship something tomorrow that’s shitty. Nobody wants to spend 10 years designing the perfect registration flow. Real impact is made by shipping something good in a timely manner. (Most people get this, and the actual debate is about what, precisely, constitutes good and what constitutes timely, but for some reason the argument often devolves into these unproductive extreme caricatures). So, what can you do to resolve this? You can explain your position calmly and rationally. You can do an analysis of what you stand to lose or gain by delaying the launch. You can agree to escalate to an authoritative decision-maker. You can get opinions from other people that both of you trust (my favorite method.) You can do some user testing, vet out whether anyone’s assumptions are wrong. On the whole, if you work with reasonable people, even if this disagreement comes up again and again, it’s not that big of a problem.
2. Can we ship this experience that feels qualitatively bad to the designer but performs well according to the metrics we track? This one is tricky because there are two ways it could play out. The first is that the designer’s point is fair, and the metrics are not tracking actual user value correctly (maybe they are too short-term, maybe they are too incomplete—i.e. good for this one thing, but bad for something else that isn’t being tracked, etc.) In which case, as a designer, you should figure out if there are other metrics to look into that would shine light onto this being a bad experience. The second way it plays out is that the designer is overvaluing their individual experience at the cost of network experience. For instance, maybe it’s not such a great individual thing for a user to be presented with an ‘invite your friends’ flow so early in their session, but long-term, the more friends they have, the more value they’ll get out of the product.
3. We fundamentally don’t agree on the product strategy. This one I talk more about in How to work with Designers, and is the prime case in which I think the designer and PM should seriously reconsider working together.

Regardless of the disagreement, it’s a hell of a lot easier to disagree on tactics when everyone is in staunch agreement about the end goals. (And if you’re not, as in the case of #3, then it may be time for a change.) I find it helpful to record such debates and return to them after-the-fact. Usually, they’re enlightening, and there are some lessons to be learned for next time. Sometimes they seem silly in retrospect. (We argued so much over that little detail? It didn’t even matter in the end!)

The quickest way to a PM’s heart is to be reliable.

Don’t be the Don Draper that disappears after lunch to find his “creative mojo” and doesn’t return until Thursday afternoon. Seriously. The creative realm is not some higher plane that excuses you from making commitments and doing your damned best to meet them. Yes, it can be difficult to predict when you’ll come up with something that meets the high quality bar you uphold. But notice I said reliable and not meets every deadline. You may not always know exactly when a good design will materialize, but you should take the time along the way to communicate what you’re doing, why you’re doing it, and when you think it’ll be done even if that’s still changing. Share your in-progress work and your process. Explain why you’re still exploring, and the reasons you’re not happy with what you have so far. The fact that you sought out your PM to talk it over gives you instant reliability cred. It helps her do her job effectively. More than that, it helps her understand you and the way you work, so that you guys will have a stronger relationship in the future.

Because at the end of the day, you, dear designer, shouldn’t just own the goals of your design. You should own the whole of the thing that your team is building. Together. Which is the only way anything great is ever done.

This is Part 2 in the installment, following How to Work with Designers: A Cheat Sheet for PMs and Engineers. Part 3 is here: How to work with Engineers.