Navigating The Overlap Between UX & Product

I bumped into a former colleague the other day and the topic of Design-led strategy vs Product-led strategy came up. It’s a common challenge: senior people in both roles often want to drive discovery and strategy.

When multiple disciplines vie for the same space, it can breed frustration that harms team collaboration and can ultimately lead to worse outcomes. And, when talented practioners feel like they’re spending more time navigating competing priorities than solving meaningful problems, it can even lead to retention challenges and burnout.

But product strategy is bigger than any one discipline. With a few lightweight processes to enable collaboration, UX and Product can drive strategy together, rather than separately. As someone who straddles the line between these two disciplines, I see real value in what each team brings to the table.

From a user experience standpoint deep user understanding can and should drive product decisions. Nobody cares how delightful the interface is if it isn’t solving the problem they came for.

From the product management side, the mandate to create value for the business is essential. But this too requires deep empathy and understanding of user problems to creates products and services that users actually want.

When UX and Product respect each other’s perspectives, we create better outcomes for users and the business alike. Here are a few lessons I’ve learned in my own work making space for these two disciplines to work together.

Roles, Not Titles

When building product teams, many turn to the traditional triad popularized by Marty Cagan and the Silicon Valley Product Group (SVPG). But it’s important to remember that these are roles, not titles — and responsibilities might differ based on team makeup or product need.

Marty himself recommends that Product and Design should sit in the same department, underscoring the importance of close collaboration. The goal isn’t to fill a triad on paper, it’s to create a team that’s greater than the sum of its parts.

Start with Trust

No framework or process can replace trust within a team.

Without trust, even small disagreements can escalate. When new teams are forming, I like to start with collaborative workshops where both parties can learn how to work with one another while also uncovering complexity. And it's best if you can find a way to do this early collaborative work and trust-building in person rather than remote.

Shopify’s product team uses the analogy of a battery: trust starts low and charges over time. At the end of the day, trust grows when you approach others as real people — lead with curiosity, respect peoples’ expertise, and do what you say you’re going to do. Remember too that building trust takes time, but it can be lost in an instant.

Shared Language = Shared Goals

Effective collaboration starts with clear communication. UX and Product need a shared vocabulary to describe problems, goals, and success metrics. When everyone is speaking the same language, decisions happen faster, misunderstandings decrease, and outcomes are easier to visualize. A shared language also helps to create alignment with stakeholders — so everyone knows what “done” looks like, and why it matters.

I like to start with 2-3 plain-language statements like “Build a better sales machine” or “Make users feel successful quickly”. Later you can layer in OKRs and business metrics, but if you can’t explain it simply you don’t have alignment yet. You know you’ve succeeded when you start to hear your words repeated back to you to frame a problem or rationalize a decision.

The best shared goals support users and the business, aligning work across teams. On a recent project, UX wanted to create a more consistent experience across product lines, while Product worried about the pushback from business unit owners who valued their unique branding. We found common ground by reframing the work as “helping each product line stand out” and “creating consistent quality standards” which helped everybody move forward together.

Discovery vs Delivery Mode

One of the biggest things that trips teams up is shifting from discovery to delivery. Each mode requires a different mindset. Where discovery is messy, exploratory, and focused on learning; delivery is more structured, definitive, and efficiency-minded.

Imagine a designer sharing work that’s ready for delivery, while the Product team questions its value and feasibility, threatening to go back to the drawing board. To the designer it feels like going backwards, and to the product manager it seems like design jumped the gun — the disconnect is a surefire recipe for frustration.

To prevent this misalignment, be conscious and thoughtful about mode transitions. Start each project phase with explicit rituals that state which mode you’re in and the expectations for the team. Be thoughtful about what goes into kickoffs and other team rituals. In a discovery session you might say “even your craziest ideas are welcome” contrasted with delivery where “we're locked on direction, but we do need input on edge cases.”

Clear mode switching reminds everybody where they are in the process. Make it explicit which mode you’re operating in, and align expectations accordingly with your team and stakeholders.

Directly Responsible Individuals

If I had a nickel every time somebody said “let's build a RASCI”, I’d be a wealthy individual. But despite the model’s universal usage, the labels can be confusing and jargon-heavy for team members. At best, it's ignored — but worse still, the process to define and align on RASCI assignments can actually end up reinforcing territorial disputes rather than supporting collaboration.

Instead, I prefer the simplicity of a Directly Responsible Individual (DRI). The model is most famously used by Apple, but other product teams use the framework too. With DRI, each initiative or deliverable has a defined person who is ultimately accountable. Others are expected to support, advise, and contribute fully, but when things get crunchy it’s obvious who to turn to.

I came onto this model informally, while doing marketing work alongside a Creative Director on a large-scale eCommerce platform. As new projects kicked off, we’d clarify “this is a UX-led initiative” (functional flows, account portals, booking) or “this is creative-led” (marketing campaigns, brand efforts). There was no extra effort or documentation needed, and the statement helped us to prioritize our own efforts as well. It’s a lightweight accountability model that works best without heavy bureaucracy or process overhead.

Of course the key is in assigning responsibility appropriately, especially when areas of interest overlap. My advice is to assign the responsible individual based on the higher-level outcome rather than task methodology. For example, if you're conducting user research that's meant to identify usability issues, UX would be responsible. If instead it’s supporting the run-up to a major launch, Product takes the lead.

Collaboration in Consulting Environments

In client work, there’s extra complexity for UX and Product teams. You’re not only designing and building with cross-functional teams in a single company Slack, but also partnering with external organizations that bring their own culture, context, and ways of working.

Teams should decide who leads conversations about strategy, research findings, or technical constraints before meeting the client. Opinions might differ, but there should be no ambiguity about who's voice carries.

Studio teams also need to make space to learn how the client's businesses actually operates — how they make money, where the real complexities lie, and how they define success. It's especially important in discovery, when both Product and Design are still learning the landscape.

It's tempting to treat milestones as approval gate where feedback and revisions slow progress. But especially in a consulting context, feedback is necessary to build shared understanding. Use each discussion, prototype, or review as an opportunity to test assumptions, gather feedback, and improve alignment.

Key Takeaway

The overlap between UX and Product doesn’t have to be a source of friction. When teams get just a few simple things right — clear ownership, shared language, lightweight accountability — everything else flows more easily. Teams move more confidently, and senior practitioners stay longer because they feel they’re solving meaningful problems rather than justifying their role.

Doing good product work is hard. But thoughtful leadership can make it easier by putting the right supports in place, so teams can focus on doing their best work.

Cover photo by Sebastien Bonneval on Unsplash