A Designer’s Guide to Working with Product Managers
Six tips for designers on getting buy-in for their ideas and improving how they work with PMs
Maybe you’re a sensitive creative type who came to product design by way of art school or another path equally removed from the concerns of analysts, engineers and business people. Or perhaps you got your start in graphic design, where you learned many skills for pleasing clients, all of which now seem useless when it’s your own team you have to convince. In any case, there’s bound to be times when your design goals clash with the goals of your product manager; you have very different jobs and often very different priorities. I’ve been gathering some hard-learned lessons from my own experiences working with PMs, and I’m here to assure you that you can still do your best work amid constraints and pushback from your team. Read on for a few tips on getting that great design of yours actually built.
1. Anticipate a PM’s objections, but still present your ideal design.
Once you’ve worked extensively with a PM, you’ll probably start hearing their voice in your head from the very start of iterating on a new design. And that’s a good thing: it means you’re familiar with the needs of your team and you’re more efficient at your job. But simply because you’re aware of potential constraints does not mean you should start off with anything other than your best design.
When I started working on a team with PMs for the first time and got to know their individual preferences, I found myself censoring my own work from the start of a project in order to avoid debate. After a few months, I was looking back on work I wasn’t proud of and certainly would never want in my portfolio. I realized I wasn’t doing the part of my job that involved advocating for the best possible design and the best overall experience for the user.
You might think you know what a PM is going to say about that colorful header or new button location, and maybe you’re right 90% of the time. Sometimes you’ll be surprised, though — you may find that engineering resources are not as scant as you thought, or perhaps there’s been a shift in priorities and your ideal design could get more traction. You never know, so go in with your best work.
2. Stress the MVE over the MVP.
Minimum viable product: a term that probably caused a sinking feeling in your gut the first time it was explained to you… So the best thing isn’t always what makes it into the final product? Even worse was when you realized how often the MVP is the only thing that actually ends up getting built. Unfortunately, it’s a crucial part of product development and a necessary constraint on your work.
But a designer’s idea of a bottom line has to be different from an engineer’s or a PM’s, because our priority is the user’s experience of the whole product. We know better than anyone that adding a seemingly harmless call to action or tweaking the layout even slightly can cause a bigger impact on the user’s focus than most people could imagine. It’s our job to stress the minimum viable experience as the bottom line. If there’s a project underway that threatens to detract from a clear and focused overall user experience, as a designer, it’s up to you to speak up about it. The MVE will continue to be lost to the MVP unless you make it a priority.
3. Speak their language (by presenting data and research).
You might be thinking, “That’s great — I do try to speak up for the MVE, but at the end of a conversation, my point of view rarely wins out.” One of most sought-after skills in product managers is being great communicators who are able to bring others around to their point of view, so you’re not alone if you struggle in those conversations.
My advice for handling those conversations is to back up your ideas with data as much as possible. Do some digging to see if there’s been user research done by other people that relates to your particular design challenge. Maybe you’re using a visual style or interaction that’s failed to increase engagement in the past—if so, your biggest source of knowledge is the people in your company who worked on that project, so ask around. Figure out why that project failed from a design perspective and make a case for why yours won’t.
Researching your designs in an early stage of iteration will improve your work before you even present it for the first time. And, if you’re dealing with a PM who has a lot of their own ideas about visual design, backing your work up with data is the best way to bring them around to your side.
4. Ask to hear the project’s goals, not the PM’s ideas for how to achieve them.
In that first job working with PMs, I made the mistake many times of executing a design that was already completely fleshed out and wireframed by someone else. Mocking up someone else’s work can make you feel like no more than a trained monkey who knows Photoshop, so make sure you’re being given room to do your job. It’s okay for everyone to have their own instincts about design, but never forget that you’re being paid for yours.
I do my best work when I begin tackling a problem with a clear perspective, so when I meet with a PM who has several pages of wireframes they want to present to me, I’ve learned to interrupt and ask instead to hear their goals for the project. Goals—along with the constraints, timeline, and scope for the project—are all you really need to go on, so don’t let your work be influenced by other peoples’ ideas for how it should look and feel to the user.
5. Go to them with your thoughts, all the time.
Designers are always complaining about how projects being staffed do little to address the biggest design problems within the product. But if you’re not regularly communicating your concerns, PMs have to steer the whole product themselves, and you really can’t complain when projects aren’t accomplishing your design goals.
At Yammer, we have a simple spreadsheet where anyone can jot down the ideas they’d like to see make it into the next project. Good PMs know how to balance offense projects (e.g. building new features) with defense projects (e.g. removing clutter and code debt), so let them know when you have a design task you want to sneak into a defense project.
6. Remember that data shouldn’t always trump your design instinct.
Your design might fail an A/B test even if it’s good, and even when you know deep down it’s a better direction for the product. For instance, if it was the first time you implemented a new visual or interaction style, the design could look or feel out-of-place. Or, since users are accustomed to certain behaviors, bad metrics could be caused by normal growing pains that result from making changes.
The first thing to keep in mind is that you don’t need to test every little change in design. Especially if your product is in need of a big scale redesign, testing every single visual change will kill your vision, slowly and painfully. Work with your PM to decide what can safely be shipped without testing. Google Ventures has a great article that can help you decide when to favor test results and when to weigh a designer’s instincts more heavily.
When you do need to test your work and the results are less than ideal, don’t just throw away the design and revert back completely. Keep iterating. Otherwise, you’re missing a great opportunity to learn from your work and your users.
Striking a balance between standing by your vision and incorporating feedback from your team is one of the hardest parts of product design. You and your PM are working towards the same ultimate goal, so keep sharing your work with them and doing the best job you can of explaining it. Seeing your process will give them a better understanding of your priorities, which in turn might make your job a little bit easier.
Have more ideas on how designers can work better with PMs? I’d love to hear them and I’m sure there are many designers out there who could benefit as well. Drop a note and keep the conversation going.
