Effective Product Manager: Work with Design

Working well with cross functional team is one of the essential skills of a product manager. In the last article I discussed working with engineering. In this one, I’m going to talk about working with design (specifically product designers), which is another pillar of the core product team.

In case you missed them, here are the previous articles in Effective Product Manager series:

• Execution
• Roadmapping
• Stakeholder Management
• Strategy
• Building Relationship
• Empathy
• Communication

—

I’ll discuss in 4 parts:

1. Why is it important to work well with design
2. What does design look for in a PM
3. Principles of working with design
4. Frequent FAQs

Why Is It Important?

Design is one of the 3 pillars of a core team (Engineering, Design, Product) that together bring products from concept to live. Design, like engineering, focuses more on the HOW’s (how to solve the problems, whereas PM focuses more on the WHAT & WHY). Specifically, they focus most on the users: who are they, what their needs are, what are their motivations, what are some challenges and pain points they’re facing in their use cases, and then how to create the best user experience for them.

Of course, PM cares immensely about the users too, just like how one should also care about the business and technical solutions. But think of Design as the function that’s specialized in user needs and experience. Their design artifacts, mocks and specs are just their outputs, fed by their deep and broad understanding and considerations for the users.

So do you as a PM, care about users and want to build the best product experience that solve their problems? I thought so. Make sure you partner well with design.

What Does Design Look For in a PM

Here’s the top ones in my experience:

1. Partnership: they want to be treated as equal partners in the product journey (vs dictatorship that treats them as mock up delivery resource). They want to be brought along as early in the phase as possible to understand users and what we’re solving for. They want to have a say in product decisions.
2. Leadership & Clarity: similar to engineering, they look to you to lead with context, rationale, and structured decision making. This does not conflict with their desire to participate in product decisions. Because at the end of the day they want you to be responsible for the right decisions to be made.
3. Respect: respect their expertise, creative native of the work, and that details matter. A button is not always just a button. It’s the whole package that makes the whole user experience.

Principles

Top 3 that have worked well for me:

1. Context, Not Control: Provide the right context: what are the business needs, who are we serving, what problems are we solving, why they’re important etc. or whatever is missing for design to do their best jobs. Give them full ownership on what they do. Don’t dictate on how to solve a problem or even how to design it.
2. Define the Partnership, Flexibly: The partnership aspect is important. It’s equally important to define this partnership flexibly, depending on your design partner’s strengths/weaknesses, preferences/motivations. There’s no one-size-fits-all line of “this is what a PM does vs this is what a design does”.
3. Explicit Feedback: to provide feedback to design deliverables, don’t just say “this is better than that” or “no this is not going to work”, but make sure you provide the why, focus on the goal and the problem we’re solving (i.e. does the design solve the problem and accomplish the goal, why or why not). Your feedback should not be based on pure intuition. Or even if you have an intuition without any data to back it up, mention that explicitly egoless.

FAQs

I value design partnership a lot. But what if I’m missing a dedicated designer on my team at this point?

Remember, a PM does whatever it takes to move things forward toward your product goals. No designer to create mocks to unblock your engineers? It’d be great if you know the basics of mocking things up, or there are numerous options you can work directly with engineering to just agree on some basic UIs that get the jobs done for the time being and worry about aesthetics later; or you prioritize some backend/infra work that requires no/minimum UI changes.

What if my design partner and I disagree on design options?

There’s always only one best answer. It’s not your preference. It’s not her/his preference. It’s to make it a structured decision, focusing back on the goal. Our goal is to improve users efficiency in this specific workflow. What are some key drivers that impact efficiency? Can we use these drivers as evaluation dimensions on the options you and design are debating about?

Design always came up with a lot of “fit-n-finish” (minor UI details) gap tickets near the roll out, and I have a hard time prioritizing these over other functionalities or projects. This makes her/him unhappy. What do I do?

On the surface, this appears to be a trade off where we balance “respecting design craft” vs” what moves the needle for the business”. I believe the better approach is to bake this into the acceptance criteria even before the engineering work starts. Making further UI changes after “code complete” for functionalities always seems like overhead. When we define it as a part of the scope and also establish the culture of building it per design spec, we would have much less trade off decision to make at the tail.

To Wrap

How do you work with Design? What are some of your tips and challenges? I’d love to hear about them! Contact me.

—

Like this article? Subscribe to join the community and receive free weekly posts!