Should product managers learn design?
“Should I learn how to code?”
Before starting my first PM role, I read as much as I could about the skills it takes to be a successful PM. “Should PMs learn how to code?” was the one question that kept coming up. So many product managers agonize over whether they should learn how to code.
However, I wonder why PMs don’t agonize over learning design as much as they do about development. Because now that I’m almost a year into it, I’ve learned that it benefits your team if you understand design.
Most answers to whether PMs should learn how to code is: “It’s not necessary to learn how to code, but it helps to understand technical concepts.” The same is true with product managers and design. PMs don’t need to know how to implement design, but they need to understand it. They don’t need to be experts at color theory or typography history, but they do need to know how the colors and type support their user’s experience.
Specifically, I’ve learned in my role at Sanctuary Computer that it helps to be able to...
Have some design intuition (so that you can give useful feedback)
Help designers understand the company’s goals
Know some design techniques, like wireframing, information architecture, and object mapping
Include designers into your workflow
Let’s expand on each point.
Product managers should have some design intuition
Pretend you’re a designer, working on a house buying website. You’re designing a way for users to easily revisit housing listings they’re interested in. You get feedback from two product managers:
PM 1 says that you should design a Tinder-like UI. Users can swipe left and right to favorite houses they like based on their preferences.
PM 2 says that the ♥ icon that users tap/click to view their saved searches is confusing. Most ♥’s mean “like this” or “favorite this” rather than “view saved items.”
Who will you listen to? If you’re a smart designer, the second one. PM 1’s feedback tells you exactly what to do, but PM 2’s feedback highlighted a conflict with the way people usually interpret a specific affordance. Feedback 1 gives you a solution with no problem or rationale. Feedback 2 gives you a problem for you to solve.
Designers want useful feedback. To give useful design feedback, develop your design intuition.
Here are some resources and tips that I’ve found helpful.
Start with understanding design principles:
Understand basic UI elements and patterns:
Do things like:
Observing design reviews before contributing. Understand how designers critique each other's work before critiquing. You’ll learn about what good feedback looks like and how designers give and receive feedback.
Tearing down your favorite apps and websites. What about these apps make them your favorite? What design principles do they demonstrate? How could they be better?
And make it your goal to answer these questions about your team’s design work:
How does the text hierarchy present the most important information to the user?
How does this typeface support the user experience?
How do these colors support the user experience?
Which design principles do we care most about?
If you think that your design intuition is already strong, check yourself! Everyone thinks this. But it’s more difficult to articulate your intuition in a useful way. Approach design with a beginner’s mind, because there’s always more you can learn.
To recap: understand design principles, observe design reviews before contributing, tear down apps/websites, and craft answers to questions about your team’s design work. This will sharpen your design intuition and enable you to give better feedback.
Product managers should help designers understand the company’s goals
While it helps to be able to give design feedback, your main way of supporting designers is to help them understand the goals behind the product.
Helping your designers understand the company’s goals is something you can do regardless of your design intuition. This is a great starting point for junior PMs. You can offer feedback in a way that isn’t about “changing this type size” or “using a checkbox instead of a toggle switch” if they understand how their designs could better meet the goals of the product.
Examples of giving feedback based on the company’s goals:
“Given that the business cares most about X, I feel like the information on this screen isn’t necessary.”
“Given that the business cares about converting users to a paid tier, I feel like there's an opportunity to upsell the user in their account page.”
I cringe when I hear product managers say they feel like it’s their responsibility to tell designers what to do. Be genuinely interested in your designer’s work, but do not do it for them. Share feedback when they ask for it, but don’t leave a million Figma comments when they didn’t ask for it. If they come up with good ideas without you, you’ve done your job.
Product managers should have some design tools in their toolbelt
In some cases, it helps to know some design techniques.
Here are scenarios for when it helps to have design tools in your toolbelt:
Your team’s designers are heads down on other projects, but you need to make progress on your product.
Your organization doesn’t have any designers, so you become the de facto designer.
You have an idea for how your homepage can increase conversion. Visuals would communicate your idea better than a spec would.
Here are tools that have helped me:
Wireframing. Showing is more helpful than telling. This is why wireframes are useful. I use Whimsical to wireframe—it’s free and easy to use.
Priority Guides. Unlike wireframing, priority guides aren’t focused on layouts. They’re focused on prioritizing the content and elements of a screen. Priority Guides give designers an idea of what content to prioritize so that they can design the interface with this in mind.
Information Architecture. Information architecture is about defining every path a user can take through an app or a website. I also like Whimsical for creating IAs.
Object Mapping. Object mapping is defining the objects in your system before defining the actions those objects can take. This is a helpful tool if your product feels messy or complicated.
This should go without saying: if you and your designer are both strong at a certain technique, figure out together who should work on what. If you want to do the information architecture, say that! If you both want to do wireframes, do it so that you’re exploring more options. Having a designer with a similar skillset as you means twice the amount of brainpower to make the work better.
Product managers should invite designers into their workflow
I once saw this in a product manager’s LinkedIn bio:
“I strive to talk multithreading and memory management with developers, sans serif fonts and color theory with designers, and KPIs and agile development with PMs.”
Barf.
PMs are told to “build credibility.” So they flex their knowledge to developers, designers, and other product managers. This harms credibility. I don’t know any engineer or designer that trusts a PM more when they are constantly trying to prove themselves.
More PMs need to see the value in facilitation. Facilitation—the practice of helping groups solve problems—is 80% of your job. Facilitation can feel counterintuitive. It feels slow: You have to wait on people’s feedback, you have to schedule more meetings, and you have to prep workshops. It’s much faster to make the call on our own. And as PMs, we must “exude certainty!” Asking questions makes us look “less credible.”
But facilitation pays off. More minds mean better ideas. Design and development contributing leads to more feasible ideas. And, your team will trust you more than if you always made decisions on your own.
PM as auctioneer, backlog owner, and facilitator (source)
I like Matt LeMay’s perspective on how product management is more about making connections than being technical:
“The truly great technical PMs I’ve met know how to invite their engineering teams into the prioritization process in such a way that the process itself is both interesting and rewarding. They know how to empower an engineering team with the information to make technical decisions that will support the company’s business goals. In other words, the differentiating factor between success and failure is not being “technical enough,” but rather being adept at making connections between different sets of values and expertise.”
Invite a designer and developer to your user interviews. Bring your workshop agenda to a design review. Ask them for their thoughts on which features are most important. Be comfortable with not having the answer to everything and getting other perspectives. When you take an interest in another person’s work and invite them into your process, they will likely do the same.
Some great facilitation resources:
Anything by Daniel Stillman
Learning design is part of the job
First, nail the fundamentals. Help your team understand the company’s goals and invite them into your process. Then get better at understanding design.
Your job is a perpetual state of learning. That learning includes design.
~
Thank you to Devin Halladay for your feedback on earlier drafts of this piece. And thanks to Conor O’Holleran for helping me see the importance of understanding design as a PM.