PM 101: Working With Product Designers
4 August 2019 ‧ 8 min read
In the “PM 101” series I am sharing some PM basics that I wish I had known when I first started as a product manager. In this article, I talk about a few best practices to better collaborate with product / UX / UI designers.
Collaborating well with product / UX / UI designers is among the most crucial aspects for a product manager's effectiveness. However, that collaboration isn't always straight forward. I will readily admit that as a new PM, working effectively with designers was my biggest challenge. I have a technical and business background, so collaborating with engineers and business-focused stakeholders came easy to me, but designers were a different breed. Of course, the working relationship with their designer is crucial for any PM working on user-facing aspects of the product, so I needed to work on that urgently.
One of the aspects that irritated me the most in the beginning was that we didn't seem to be following the double diamond design process that I had read about:
The double diamond process looks nice and tidy: diverge, converge, diverge, converge. What happened in real life was that the designer I was working with would come to me and say: “You know this solution idea we agreed on a few days ago? Forget that, I had a few much better ideas!” I had to bite my tongue in order not to say “We were converging, why are you diverging again?! I thought we had an agreement!”
A few months into my first PM role, I came across a different illustration of the design process, the design squiggle:
The Process of Design Squiggle by Damien Newman, thedesignsquiggle.com, licensed under CC BY-ND 3.0 US.
The design squiggle also shows eventual convergence and clarity, but it also shows the messiness of the early stage of the design process: the path criss-crosses, meaning you sometimes have to go back to where you were earlier, and it changes direction many times. In the beginning, what direction you are taking overall isn't at all clear.
Seeing the design squiggle for the first time made things click into place for me: I was trying to impose too much structure on a messy process, and I had expectations for linearity that were incompatible with the reality of how design (and hence designers) work. This insight was the first critical ingredient for me to work more effectively with design.
In addition to and based on this realization that sometimes the design process is inherently a bit messy and non-linear, here are some tips for how make the interface with design more effective as a product manager:
- Agree on responsibilities and way of working
- Start with why
- Focus on the user, educate about the business
- Define the problem before the solution
- Provide space for creative chaos
- Be crystal clear about expectations
- Make only promises you can keep
More details on each of these points follow.
Agree on responsibilities and way of working
Especially in the early stages of the product or feature development lifecycle, the delineation of responsibilities between PM and designer is blurry and differs from organization to organization. In bigger organizations, these responsibilities may be clearly defined (and you may have more specialized resources, e.g. for user research and UX copy), but in smaller teams you may have to sit down with your designer and define responsibilities, e.g. in the following areas:
- Who does competitor and market research to inform our direction?
- Who comes up with the solution idea(s)?
- Who makes wireframes? Who defines the overall user flow and how is it documented?
- Who writes specs / user stories / tickets?
- If user testing is required, who prepares / runs the test?
- Who writes UX copy?
In addition, every designer has a different working style (and of course, so does every PM). So even if the responsibilities of PMs and designers are already clearly defined in your organization, you should still understand your designer's preferences by answering these questions:
- How often do you want to check in, and in what form?
- Do you prefer to discuss rough work-in-progress, or do you need to finish your thinking and share more completed designs?
- How would you like to be given feedback?
- What is the best way for me (as a PM) to share ideas I have? E.g., share wireframes, joint whiteboarding sessions,…
Start with why
Whatever you are working on, be it a big initiative or a tiny improvement, the best way of ensuring a smooth collaboration with design is a good alignment on the fundamental direction. This means “starting with why” on the highest level: how does what we are about to do contribute to our company and product vision? How does it help us achieve our strategic goals?
The product manager is frequently the first person working on an improvement effort and needs to establish that link with the product vision and strategy, and then communicate it to everyone who comes on board. The designer is most often the second person on the team when the direction is still very ambiguous, so it falls on the product manager to make sure this alignment on the higher-level purpose is rock solid.
A good practice is for the product manager to write down this link to the vision and strategy explicitly. If the link isn't clear enough, writing it down will be difficult: that's a red flag that some additional clarity is required. Perhaps the PM was given this assignment by someone in product leadership who wasn't clear about the link themselves. In any case, starting off without a shared understanding of this link between PM and designer is an unstable foundation for the working relationship.
Focus on the user, educate about the business
Product managers sometimes have the (bad) habit to talk about everything from the perspective of (business-related) product goals and metrics: “We are doing this to increase engagement / retention / conversion”. Designers, on the other hand, are trained to think from the user's perspective. If you try to reach alignment only on the level of product objectives, you might not be speaking the same language (no user ever said “I wish this product retained me better”).
The trick here is to answer the following question: “which user pain point are we addressing in order to change user behavior to positively impact our product metrics?” For example, you might improve conversion rates in a checkout funnel by reducing friction for users, improving the information shown to users, improving pricing, etc. All of these have real user benefits that should be the center of attention and subject to agreement and alignment between PM and designer.
Of course, it is still relevant to talk about the business-related product metrics. Often, strategic goals will be expressed in these terms, so it will be hard to link the work to strategic objectives if you only talk about user needs. The formula above provides the answer to this as well: you can use it to communicate to the designer how solving the user problems will positively impact the product metrics and therefore help achieve the strategic goals. Senior product designers will often be able to make those connections themselves, but more junior designers might require some explanation about why moving certain metrics is beneficial for the company.
Define the problem before the solution
A previous post in the PM 101 series was entirely about this topic: it is essential to not just work on feature ideas, but instead work on solving problems. Therefore, the first thing that PM and designer need to collaborate on is a clear definition of the problem.
If you just start working on a feature idea without a clear definition of the problem that feature is intended to solve, then everyone will have a slightly different understanding of the problem that the feature should solve. That difference in understanding between PM and designer can lead to painful miscommunication and misalignment, for example when the designer comes up with new ideas that better solve the problem in the designer's head but are a worse fit for the problem in the PM's head.
Provide space for creative chaos
The best way to react to the realization that the creative design process is inherently messy is not to put it in an even stricter and tighter process corset, but rather to allow space for creative exploration and expanding the horizon of what's possible. This means that especially in the early stages, the designer's creativity should be given free reign.
Even better is to facilitate this chaotic process through techniques that stimulate creativity (for example, from the Design Sprint toolkit). The product manager should definitely get involved as well, and ideally engineers and other stakeholders should be brought in too. Engaging everyone's creativity in this way will both lead to a better product and motivate and excite the team.
Of course, there's a time for creative chaos and a time to efficiently deliver. The crucial point here is to be crystal clear about expectations and when you are moving from one phase to the next, see next section.
Be crystal clear about expectations
Very often, friction that arises between PM and designer is due to unclear expectations and the miscommunication stemming from that. The PM expects the designer to deliver a solution, and the designer keeps exploring options since they weren't aware that the devs need something to build in the next sprint. The PM says “I like that option, let's move on with that” and expects the topic to be resolved, but the designer has not bought in and keeps thinking about different options.
The solution to this problem is to be crystal clear about expectations and agreements, overcommunicate them, and get buy-in from the design side. The discovery and design work is done in partnership between PM and designer, if one of them doesn't have the same expectations and assumptions as the other, then those expectations and assumptions aren't valid.
Here are some points to explicitly and jointly agree on, document, and regularly re-affirm:
- Time line / deadlines: how much time do we have? Do we have to have designs ready by a certain time?
- Scope and constraints: is this a small incremental change where we shouldn't rock the boat, or do we have the mandate to more fundamentally challenge things? What can and can't we touch? Are there any non-negotiables?
- Assumptions and hypotheses: what assumptions are we making, and what hypotheses do we have? What data / information are they based on? How will we validate them?
- Process stages and decisions: are we currently diverging or converging? Which option did we select and why? How final is that decision? What would we do if future information gave us reason to believe the current decision is no longer the best one?
Make only promises you can keep
One common point of contention between PMs and designers is that designers want to ship an experience they can be proud of, with high levels of craftspersonship and user delight, and PMs care about getting something out the door as fast as possible (in the ideal case, because they want to learn from having the product out in the field, not because they are measuring outputs instead of outcomes). That leads to points of contention. “We'll address that in v2” is a phrase that designers dread, since they know v2 might never come.
As a PM, be better than that. Try to understand the concerns your designer has, and if you do need to deprioritize them, at least admit it and own up to it. Don't promise a v2 that might never come. You are cheating yourself with that as well, and undermining trust of your designer.
Often it is also advisable to give the designer a little bit more leeway in adding polish and delight than you think would be necessary from a pure MVP standpoint. For one thing, in today's world a good user experience and user delight does matter, and in addition, it will make the designer prouder of their work and therefore happier and more motivated in the long term.
I hope these tips were useful and they can help you avoid some of the mistakes I made, and improve the working relationship between PM and design.
If you liked this article, feel free to follow me on Twitter for more thoughts and interesting reading about product management.