The Design Relationship

A love story (sort of).
Last Tuesday, I found myself staring at a Figma comment that read, “Would be good to explore some more ideas.” Translation: “You’re not there yet.”

The unwritten rule is that nobody says what they mean in design reviews.

As a product manager working with designers, I sometimes feel like we are in an arranged marriage, where both parties secretly think they should be in charge of the household budget. We're forcibly bonded by organisational structure, yet perpetually jockeying for control of the product's direction.

Image

And like any relationship worth keeping, it's gloriously messy, occasionally passive-aggressive, but ultimately worth the effort.

When territories collide.

The PM-Designer tension isn't imaginary. The overlap in our roles is an integral part of our structure. In my first product role, I assumed I owned the "what" while designers owned the "how." Life was simple then. I was also monumentally wrong.

The reality is far murkier. Both roles are deeply invested in user experience, product strategy, and feature prioritisation. Both have strong opinions about solutions. Both want the final say.

Laura Klein, product expert, identifies this fundamental tension: "In some organisations, there's a troubling split: the product manager is in charge of the business but the UX person is the defender of the user. And they have to battle it out in the octagon."

Once, while working on a critical feature launch, our designer and I spent three hours arguing about a dropdown menu. THREE HOURS. I insisted that it should show the five most recent items. She wanted it alphabetical. We both acted like democracy itself hung in the balance.

The language of passive-aggression.

The friction often emerges through coded language. PMs and designers have developed advanced techniques to express displeasure, like specialised regional dialects, while maintaining plausible deniability.

According to actual designers, when I say "I like the designs but..." it universally translates to "I don't like the designs." When designers tell me "No, there are no bad ideas" after I've shared a concept, they politely say, "That was a bad idea and I'm worried about your cognitive abilities."

My favourite is receiving a Figma prototype with 47 comments beginning with "Just a small thought..." Each "small thought" requires redesigning an entire user flow. Nothing says "I respect your timeline" like suggestions that would add three weeks to the schedule.

The ownership struggle.

During a particularly tense project, I witnessed the classic ownership dance. I'd make wireframes to save time. The designer would then remake them completely to "clean them up." I'd then tweak their designs without telling them. They'd discover and mysteriously be "sick" for our next three meetings.

We've all been there – that moment when a designer presents beautiful mockups and a PM immediately says, "But what if we just..." followed by a suggestion that unravels their entire concept. I've been that PM. I'm not proud of it.

As one designer bluntly put it when I used the phrase "my designers" in a meeting: "Never, I repeat never, say 'my designers' – and furthermore, never think that they are." Lesson painfully learned.

Finding a better way
(After exhausting all other options).

After enough battle scars, my team and I stumbled toward better collaboration, not because we're exceptionally enlightened but because dysfunction was eating our souls.

Jackie Bavaro, former Head of Product at Asana, describes the crucial distinction that helped us: "PMs are responsible for picking the right problems to go after, defining the goals and determining if the solution meets the goals. PMs aren't responsible for designing the solutions."

This simple clarification shows that PM owns the problem, and the designer owns the solution, creating breathing room in our relationship. It wasn't perfect, but it gave us a starting framework.

The double diamond approach.

We eventually adopted a version of the "double diamond" product development model that Bavaro describes: "First you focus on and do some expansive thinking around the problem, making sure that you're solving the right one... Once we've narrowed the problem we want to solve, we do another round of expansive thinking about the possible solutions."

When we consciously separate problem exploration from solution exploration, something magical happens – both PMs and designers feel ownership over the right parts of the process.

My favourite outcome was when our designer created something entirely different from what I envisioned, which brilliantly solved the core problem. I could evaluate it against our goals rather than my preconceived solution.

Building the relationship muscle.

The best PM Designer relationships work like collaborative partnerships rather than hierarchical management. As one design leader put it, "It's pointless to meet each day... but when the workload is tough, having a meeting once a week also is not enough, so meeting twice a week seems to be the optimal solution."

We established design crits twice weekly, where designers gathered to exchange feedback. As PM, I attended but deliberately spoke last, which stopped me from contaminating the design conversation with business concerns too early.

We also realised that transparency across teams was crucial. We started documenting roadmaps and projects in shared spaces, with designers updating their weekly goals in a single document. This seemingly small change dramatically reduced the "why wasn't I consulted?" syndrome.

When it actually works.

The strangest part of improving our PM Designer relationship was how much more enjoyable work became. Problems that once required excruciating meetings to resolve started working themselves out naturally.

Designers began proactively addressing business concerns I hadn't even raised. I found myself advocating for user experience improvements before designers mentioned them.

In our best moments, we moved beyond the narrow "I do this/you do that" mentality to what Laura Klein advocates: "We all should understand and care about both the business and the users."

My most productive designer relationship eventually turned into genuine friendship. We still disagreed frequently and passionately, but with mutual respect and expertise.

Finding the right balance.

Building this relationship isn't a one-time fix but ongoing maintenance. Sometimes I still get the dreaded "would be good to explore more ideas" comment. Sometimes I still respond with a thinly-veiled "the CEO wants it this way."

But now we both know what we're saying. And we usually laugh about it afterwards.

The PM Designer relationship works best when we acknowledge the natural tension but focus on our complementary strengths. Like any good partnership, it's not about eliminating differences, it's about using them productively.

As for me, I've learned to save my wireframes for private sketching, ask questions before making suggestions, and never, ever use the phrase "my designers" again. Progress comes in small steps.

And that Figma comment I mentioned earlier? I took a deep breath and replied, "You're absolutely right. Let's explore together." Surprisingly, we created something better than either of us had initially imagined.

Sometimes the best design solutions come from a little productive tension, just like the best relationships.

Keep Reading

ALL POSTS