10 tips to strengthen your Product Design and Product Management relationship

The Product Design (PD) and Product Management (PM) relationship can certainly be a tricky one. Like all high collaboration roles at any company, managing this can certainly make or break your experience.

Elle Shwer
UX Collective
Published in
8 min readNov 5, 2020

--

Co-written by Allison Mui & Elle Shwer.

For anyone who is struggling to build a healthy collaboration with their respective peer or anyone who is about to work with a PD/PM for the first time, we hope these 10 tips will you optimize your PM and PD relationship.

The Difference Between Product Design and Product Management

It’s valuable to understand the roles and responsibilities of each role in order to find success within your own role. By knowing what that person is focused on, it becomes easier to engage with them and make more productive decisions.

Product design and product management overlap in a venn diagram.

As a product designer, you work through each part of the user’s experience. Not only crafting the visual details to add delight and consistency, but also creating interactions that optimize usability. You spend your days talking to users, conducting research, obsessing over pixels, and perfecting the user experience.

As a product manager, you identify the vision for the product, communicate it broadly, set a strategy with tactical goals, and act as the connector of engineering, business, and design. The product manager should understand how the product relates to the business strategy, aligns with user goals, and how its’ success is measured. Additionally, when focused on tactical goals, the product manager prioritizes each problem, conducts requirements gathering to garner a deeper understanding of each problem, and oversees the entire process to ensure alignment.

However, oftentimes to build a world-class product, these lines can certainly get blurry. There are times where, as a PM, you’d have to put on a PD hat and vice versa.

Here are some examples of things we both do:

  • Research the industry and our competitors
  • Identify problems and opportunities within the product
  • Define the problem in greater detail
  • Align with stakeholders
  • Advocate for the users

All of these tasks are quite entrenched in our day to day and have helped us create an effective partnership.

Optimizing the Product Design and Product Management Relationship

As we mentioned above, the overlap makes things a bit murky. The way we’ve combatted this is by having a few rarely mentioned rules.

✨ Do’s ✨

1. Take time to understand how the other person works.
Everyone works differently. One thing we both did when we started working together was learning each other’s quirks. It’s good to learn over time or openly discuss strengths, weaknesses, and interests. This will help each individual set their own expectations of the other.

For example, not all product designers are keen on conducting all of the User Research and would prefer to utilize a User Experience Researcher (UXR) to help support the process. It’s important to know this because then you know if you need to advocate for those resources on the team or get bandwidth from the UXR at the organization.

Another example would be that some PMs’ scope of work can be more / less high level and therefore their participation in the product process varies. Some PMs like to review every iteration of design or research, whereas some just want to see the final product.

Another part of understanding each other is figuring out each other’s communication style. This is especially important when it comes to expressing feedback. How a person likes to receive feedback can differ a lot from person to person. In high collaboration partnerships, more often than not, you will have different ideas than your partners. That’s perfectly OK, it just makes it that much more important to be mindful in how you express it.

For example, your partner might prefer their feedback blunt. This might be a signal that you can communicate without a filter, respectfully of course. On the other hand, your partner might prefer their feedback with reasoning. This might be a signal that you should gather outside information to make your feedback more persuasive.

Additionally, it’s valuable to understand your partner’s work ethic and schedule. Fortunately, we both usually are online from 9–5 every day so we don’t have to always coordinate our communication — but this is actually abnormal for our broader company as a whole whose hours are usually 10–6.

2. Define each other’s roles and responsibilities.

PD and PM in a t-chart

One activity we regularly do at the beginning of every project is from the Atlassian Team Playbook. The gist of the activity is we look at an upcoming project, include any key players (oftentimes Research, Engineering, or our Information Architect), and fill out a spreadsheet on “what I think I do” and “what I think you do” in the project. Then we review everyone’s summaries to determine what overlaps or assumptions have been made. This really helps us align up front on who owns what within a given project.

3. Strive to create a not strictly work relationship
Admittedly, we all know work can be quite stressful and approaching this relationship with a certain degree of openness can actually help alleviate that stress. We believe that there are benefits to attempting to make the relationship not strictly entirely about work. By the way of things, if you both ended up in “product” at a similar company, there are likely other things you have in common. For us, we are both interested in design and user trends, excited by new technologies, and enjoy writing blogs together! These commonalities create a safe space for us to talk about how we are feeling any given day, our actual bandwidth, and what is out of our comfort zone.

4. Have trust in the other that they are doing what is best for the user and product.
It’s important to support each other. At the end of the day, we know we both want the same thing: the best for our user. If the other makes a decision, do your best to truly listen and understand their decision-making process. For us, we’ve made it an unspoken rule of thumb that unless you truly 100% disagree, trust that the other is doing what is best for the user and the product.

5. Act like a partnership.

Gif of Spongebob and Patrick high fiving

Because of the nature of the roles, accept that there will be times where your roles overlap. Instead of letting these moments cause friction, we use them as an opportunity to broaden our perspectives. We always welcome each other’s ideas and act like equals instead of a hierarchical dynamic.

⚔️ Don’ts ⚔️

  1. Product Management does not wireframe.
Wireframes no / ideas yes

While this is common in some companies, especially when design resources are lacking or the value of a PD has not been established, it is something we avoid at all costs. Plainly, it is overstepping the boundaries — a PM was not hired to design, the PD was. Typically a product manager also doesn’t have the formal training and creating quick mocks in your computer’s default design tool can be particularly insulting to the trained professional. Also, we tend to believe that if the PM cannot explain their vision or idea well enough via user stories and requirements alone then perhaps the problem isn’t well defined enough. We do encourage however opportunities to do collaborative brainstorming around look and feel like through a design studio but in these exceptions, it is up to the PD what they want to include/exclude.

2. Product Management avoids defining the design solution.
As a follow-up to PM’s not wireframing, PMs should also avoid explicitly defining the design solution. By this we mean that a PM should never claim that “a button should be used in the design” or “a certain element has to be in this spot”. This may seem strange, as it is likely that the design will result with said button or element anyways, but in explicitly naming what the design should look like the PM may actually be unintentionally excluding a better design option that they hadn’t even considered. PD should be enabled to make these design decisions and explore all the possibilities to return the best possible user experience.

3. Product Design does not proceed until the project is clearly defined.

Girl next to a check mark item

PDs should avoid, if possible, kicking off a project without a clear problem defined. Having this not only ensures alignment amongst all of your stakeholders, but also ensures you have a specific user need to solve for. Without this, your research plan, your wireframes, etc. could be ill-informed.

For example, some ways in which we clearly define a problem is by including: the motivation, a user story, a target persona, non goals.

4. Product Design does not proceed until there is stakeholder approval.
Be sure to ensure your stakeholders are on the same page before kicking off your project. This will save you and everyone involved not only time but headaches! You never want to be at the heart of pushing controversial work. It’s much better for you and everyone’s sake to push work that everyone believes in together.

5. Product Design and Product Management never contradict each other in a meeting.
Please! We beg you! Don’t do this! When either product position contradicts the other in a stakeholder meeting it completely undermines the other person and degrades the trust of the stakeholders in the room. The best approach is to take notes of feedback and criticism and reflect together after the meeting is over. Alignment early and often is pivotal to the success of the projects. Without alignment, projects can be derailed within one meeting, scope creep can occur quickly, and original user experience goals may dissolve.

Good Luck!

We hope sharing our relationship has shed some light in what a PD/PM partnership could look like. Note that these are guidelines for us and no means rules for every relationship.

These guidelines have certainly helped us accomplish a lot together and helped us create a healthy and special relationship.

We wish you the best of luck in whatever phase of your career you are in!

Elle and Allison highfiving
Our attempt at a virtual high five :D

Elle Shwer has been at MongoDB for cumulatively 2.5 years. The first portion of her tenure was as a product designer and now as a product manager for the past year (read more about her transition here).

Allison Mui has been a Product Designer at MongoDB for 1.5 years.

Together, we’ve been working together for a little over 1 year on the Documentation Platform team at MongoDB. Everything docs.mongodb.com is our bread and butter — from the internal tooling for the writers who create the content to the reader experience for those learning and using MongoDB.

Our vision is to help our readers meet their learning objectives effectively and efficiently with MongoDB Documentation.

The UX Collective donates US$1 for each article published in our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.

--

--

Published in UX Collective

We believe designers are thinkers as much as they are makers. Curated stories on UX, Visual & Product Design. https://linktr.ee/uxc

Written by Elle Shwer

product manager @mongodb // u-mich alum // creator // traveller // music + soccer fan // elleshwer.com

No responses yet

What are your thoughts?