Why designers should trust PMs and how to gain their trust
Have you ever asked yourself which qualities a Product Manager is looking for from the designers they work with? I recently did a 360 survey with some co-workers I’m working with to ask them this question. I asked designers, PMs and engineers, and some leaders from within the company I work for.
I got some interesting and helpful suggestions on what I should stop doing, keep doing, and start to do to work better with my extended team. The feedback I received brought both confidence and inspiration, and then I thought it could also be beneficial to get similar insights from PMs outside of our company on what they want from the designers they work with. I used usertesting.com to run a survey, which I use very frequently to validate and test designs in a short turnaround to collect the info.
Quick research shows some PMs feel they are not trusted by designers
Participants
I started with getting some responses from PMs. There were 15 participants (max 15 for each session) for this test. 2 participants had 2–5 years of experience and 4 had more than 10 years of experience. The rest had 5–10 years of experience in PM roles. Not a big pool of people, but I still learned some new things.
Questions that were asked:
- Tell us a bit about yourself and the job you do.
- What are the most critical skills to be a great product manager?
- What’s the most efficient way for you to validate a problem/product idea?
- How do you usually kick off a project?
- Can you describe how do you usually work with designers? What’s the process like?
- What defines a great product/user experience designer that you would love to work with?
- Name 3 things that you think designers should know( but usually they don’t) about PM? Any example?
- What are the skills or knowledge that you found most designers lack?
- Have you experienced or know of any typical mistakes that designers usually make? Please give examples.
- Have you experienced or know of any good practices that designers should start doing? Please give examples.
PMs felt that designers don’t trust them enough
When asked about what makes a good designer, most of the qualities PMs responded didn’t surprise me. For example, good designers need to have empathy, understand the business, understand the problem, know your users, understand limitations or technical challenges, and collaborate and communicate well. However, one thing that really strikes me is that PMs felt designers don’t trust them enough (they didn’t put it in the exact word) but you can totally sense this from their responses.
Here are a few examples from the responses:
“PM drives the scope of the product, they understand the relevancy, they are the driver.… Designers don’t keep the PM in the loop, big NONO”
“…Understand and respect the logic for where the request comes from”
“Many PM also have good user experience background. Share the right respect…have nice open conversations about it”
“it is on PM’s hand to explain the result, if they get a different idea, be open-minded.”
“really no such thing as a pure PM, they all come from a certain aspect, some more tech, more design, more marketing”
Why designers should trust PMs
PMs have info about customers and users
Even though PMs don’t always know more about users than designers, it is their job to explore the problems and solutions to initiate a project. Designers can and should ask questions about the customers and users, get data about some of the current situation or user behaviors. PMs may have this info on hand, or not, but they have ways to get that, just a matter of effort and cost.
PMs understand the problem, solution, strategy, and business logic
Not all designers are involved in the roadmap planning (depending on company culture) and oftentimes, it is the product team driving the roadmaps and milestones. Designers should trust PMs that they do their homework (we sometimes are involved as well)to bring projects that align with the business logic and strategy and move towards their envisioned product.
PMs prioritize and scope
PMs prioritize and scope projects. Their goal is to find the right balance between maximum business impact and minimum cost, then plan accordingly. The product is revolving, not finalized, which is why design scope is usually impacted by the product roadmap.
PMs come from different backgrounds: design, marketing, tech, professional services…
PMs usually come from different backgrounds. I have worked with PMs who used to be on the PS (professional service) team, who worked on hardphone engineering, and PM who used to be a designer himself.
Many of them have good design sense and they really know a lot of interaction details or various cases that designers may easily miss. So don’t feel offended when they give feedback.
How to gain your PMs trust
Confidently push back, address how your designs can allow/disallow problem-solving
It was rather surprising to learn that PMs like designers to push back, either on certain requirements or some feedback they give. It only showcases your professionalism and care for users if your argument indicates how the proposed solution/design/decision allows or disallows problem-solving. Your argument needs to be rational, logical, and subjective. PMs are counting on designers to give feedback to help the project move in the right direction. Don’t hold your opinions to yourself. This is when 1+1>2.
Understand the space, understand the user jobs, workflow, not just that one user story
The truth is, designers don’t usually get a big project to design an entire system or entire workflow all the time. Most of the time, you get small requests, but I urge you to think beyond that small request. Think about how it can affect the whole journey, as well as other areas. Understand the problem space, what the user is trying to do. Even if you were only asked to add a button, don’t simply add a button, understand why that button is even needed? What is the user trying to do? Is this page used in other places? Will this button be used somewhere else? Think holistically and systematically. Design local, think global.
I like the way Shopify put it as one of their design guidelines.
“Think bigger than any individual task or product. Understand the context users are working in.”
Provide options
Designers(regardless of how much experience you have) should explore multiple design options at an early stage.
Firstly, there are always different ways to solve the same problem, and people think differently. Force yourself to think through solutions other stakeholders may potentially be looking for help avoiding the following scenario:
In a review session, you’re sharing your one proposal and the PM asks “Have you tried …?” “Can we do it this way?” “ Can you provide a mockup if we …”
If you have already explored these, you can confidently push back with reasonings and explain why you want to go with the solution you proposed here. Remember, exploring here doesn’t mean you have to come up with the whole design details, it just means to think through the journey and have maybe 1 or 2 key screens.
Secondly, exploring options makes us more open to feedback, suggestions, and new ideas. If you only have 1 idea and you worked on it so hard, you feel inclined to change emotionally. Actively trying different solutions yourself makes you more open.
Thirdly, project scope(which can change midway) and feasibility feedback from engineers greatly impact the design. I usually try to provide 3 high-level options (again, here mainly means think through the flows, not necessarily you have to create a lot of mockups): best experience (usually most expensive) → better experience (less expensive) -> good experience ( minimal effort). By doing so, I feel I’m prepared for any requirement or scope changes.
Lastly, for small interactions, be sure to explore layout, pattern usages, and even copy. Note down the pros and cons, know which one you prefer yourself, voice your opinions on behalf of users, take feedback openly.
Open and flexible
Be open-minded, give some love to the ideas you don’t like. Accept that people who are not designers can come up with good design ideas too. PMs, engineers, QA, and any stakeholder can have good design ideas. Don’t feel that you’re belittled or less capable if the bright idea is generated by others. This is the power of team collaboration. Also, accept that you can make mistakes and it is totally fine and is appreciated. As well respect reality, there are limitations from different perspectives. Aim for ideal solutions, be flexible to compromise as well.
Have a process to avoid burnout
Build a process that avoids causing you burnout. Learn to prioritize, get comfortable to say No, build a design system that allows you to do more work with less time, take vocations…
Attention to details
Many designers claim they are paying attention to details, but they are not. Remember details are expected at different phases, enforce it at the right time. It’s more than having the right pixel, the right placement of the button, or no typos. It’s also about interaction details. What happens if this or that, good designers optimize for happy paths and main cases, but respect the reality and also think through detailed cases.
Talk to other designers consistently
I believe most design team has an established review process, but still, talk to each other in other occasions as well. Brainstorm together, exchange thoughts, get inspired, collect feedbacks, get aligned… Communicate often to avoid silos.
Communicate up-front
In the professional setting, no one likes surprises unless it’s a promotion or a big rise in the company’s stock price;) Don’t surprise PMs with designs that have not been communicated. If it’s not the right direction, it may waste the team’s time and delay the delivery.
All in all, building trust between PMs is critical for a designer to succeed in his or her work.
