Every few years, companies rediscover the same idea:
“Let’s bring product and design closer together.”
Sometimes that means tighter collaboration, which is good! Sometimes it means collapsing design into product management, which in my experience has always been… less good.
On paper, it sounds efficient, with fewer reporting lines which should lead to faster decisions and make sure everyone aligned, right? In practice, it often means one perspective quietly wins, and the product is worse for it.
The mistake is treating this tension as inefficiency. It isn’t. It’s a safeguard, and when you remove it, the product degrades in ways that are hard to see at first, but compound over time.
The industry keeps trying to remove tension between shipping and experience, but that tension is not a problem to solve—it’s a system that I think is worth nurturing.
Two lenses, same product, different incentives
Product management and product experience look at the same product and optimize for different outcomes.
Product Management optimizes For:
- Market viability and revenue
- Roadmap throughput and commitments
- “Is it good enough to sell?”
Product Experience optimizes For:
- Time-to-value and usability
- System coherence across the product
- “Are we quietly introducing friction?”
Same product. Different optimization functions. Different outcomes.
I spent enough years in my career as a product manager to know that, often, I was quietly eroding the quality of our product when…
- a competitor shipped something and we felt urgency to respond;
- sales was asking for roadmap commitments to close a deal; or
- leadership wanted a narrative about something off strategy.
I’d look at an idea or a feature and think “Is this great? No. Is it good enough to ship? Sure.” and I’d ship it.
In contrast, when I worked as a UX lead, recommendations grounded in research and consistency were regularly deprioritized or watered down because they didn’t fit the immediate plan. Not because they were wrong, but because the system rewarded shipping over quality.
What happens when you collapse the two?
When designers report into product management, something subtle happens: the incentives align. That sounds good until you realize what you’ve removed. You’ve taken the only group explicitly thinking about usability, cohesion, and long-term clarity, and put them under the same pressure to ship and drive revenue.
Guess what starts to slip? Not catastrophically, but incrementally, and it’s hard to catch…
- Interaction patterns start to diverge
- The same concept gets named differently across flows
- Onboarding quietly accumulates friction
- Documentation lags behind reality
Individually, each decision is defensible. Collectively, the product gets harder to use.
Cohesion is one of those things everyone agrees is important but nobody is explicitly measured on. It doesn’t map cleanly to a feature, it doesn’t have a neat revenue line, and you can’t easily slot “it” into a sprint.
For example, two teams might solve the same problem differently, both reasonably, but now users have to relearn the product each time. The result is a product that works, but feels inconsistent, like it was assembled, not designed.
A centralized product experience function at least gives cohesion a fighting chance because someone is actually accountable for the overall product experience, not in theory, but in practice.
You don’t have to choose between being embedded with product teams and being a distinct function. The best setups do both. Designers and writers should be embedded in squads. They need to be in the room and shape decisions as they happen, but they should also need part of a broader product experience organization that maintains standards, systems, and a shared bar (and directly supports their personal growth as craftspersons). Remove the second part and teams drift. Remove the first and you get ivory tower design.
Plenty of successful companies lean heavily product-led with embedded design. Amazon is often referenced for having strong product ownership, fast iteration, and an experience that can feel… uneven, depending on where you are. Apple is the canonical case for prioritizing design coherence at the highest level with strong, centralized control over the experience. Slower in some respects, but extremely cohesive.
Then there’s a middle ground.
Companies like Stripe and Airbnb invest heavily in design systems, content, and experience quality while still maintaining strong product management discipline. Companies who define their markets with product-led, best-in-class user experiences don’t pretend the tension doesn’t exist, they operationalize it.
You can argue causation, but you can’t ignore the patterns:
- If product management dominates completely, you tend to get a product that grows in capability and declines in usability.
- If product experience over-rotates without enough connection to market reality, you risk building something elegant that doesn’t actually matter.
Neither failure mode is rare.
So how does Product Experience actually drive outcomes?
This is the part that usually gets hand-waved. If product management owns the roadmap, how can product experience be accountable for anything real? If you don’t have product managers reporting to you, aren’t you just influencing from the sidelines again? It depends on how you operate.
Product experience doesn’t need to own the roadmap to shape it, but it needs leverage in a few specific places:
1. Paying for experience up front
This is the most important part, and the part that most teams avoid: if experience improvements are funded with whatever time is “left over,” they won’t happen.
There is never any leftover time, so product management and product experience need an explicit agreement.
A portion of every roadmap must reserved for improving the product itself. Not new features. Not net-new capability. Improving clarity. Reducing friction. Fixing inconsistencies. Paying down experience debt.
Let’s say 10%, maybe 20% if you really care. The exact number matters less than overall the commitment. It’s the same logic as saving for retirement—if you wait until the end of the month to see what’s left, you won’t save anything. If you take it off the top, it compounds.
Experience works the same way. Small, consistent investments in usability, cohesion, and clarity compound into a product that is easier to adopt, easier to expand, and harder to churn from.
Importantly, this investment needs to be visible to the business. If you’re reserving part of the roadmap for improving the experience, you need to know if it’s working. You have to answer the business’s ultimate question: Are we getting our money’s worth?
You prove it by translating product friction into business costs:
- Time to value isn’t just a usability metric; it’s what drives shorter sales cycles and faster enterprise deployments.
- Task success and drop-off aren’t just funnel metrics; they are the strong indicators of Net Revenue Retention (NRR) and churn.
- Support load isn’t just about frustrated users; it’s a direct operational cost eating into your margins.
Track these metrics not as a dashboard for its own sake, but as feedback on whether your investments in product experience are actually protecting revenue and reducing operational drag. Otherwise, experience work becomes indistinguishable from preference, and it’s easy to cut the next time priorities shift.
2. Defining and enforcing quality at the system level
If usability, clarity, and cohesion are treated as “nice to have,” they will lose every time. If they’re not part of the definition of done, they’re optional, and optional work doesn’t survive roadmap pressure.
Product experience has to set non-negotiable standards. Interaction patterns, content models, accessibility, and system behaviours.
But standards alone don’t hold. They need to be encoded into systems. Design systems. Content systems. Interaction principles. These aren’t just libraries, they’re control surfaces. When they are well-run, they quietly shape every roadmap decision.
A product team can choose what to build, but how it fits into the system is constrained by these layers. That’s real leverage.
Product Experience shouldn’t ask for permission to improve things, they need to define what acceptable looks like, and build that into how the product gets made.
3. Being there early, with a way to push back
If product experience shows up at the end to “polish,” it has already lost. The leverage is upstream: framing problems and shaping solutions early.
This is why embedded teams matter. You’re in the room when decisions are still fluid, not after they’ve hardened.
But being in the room isn’t enough. There will be disagreements, and there should be disagreements as part of a healthy tension. If product experience is only present but not empowered, it becomes advisory again, and “advisory” doesn’t win when timelines get tight.
There needs to be a clear path to push back when something materially impacts the experience. Not for every pixel, but for the decisions that compound.
If everything rolls up to product, those disagreements resolve in one direction. If product experience has its own leadership and escalation path, those trade-offs stay visible.
That’s what keeps experience from getting negotiated away, one “reasonable” decision at a time.
If everyone owns it, no one does
Product management decides what to build and when.
Product experience shapes how it comes together and whether it actually works as a system.
If both are functioning well, neither is optional. Instead of arguing about reporting lines, it’s worth asking something more concrete: Who is actually accountable for the experience of the product?
If “everyone” owns product experience, no one is actually accountable for it.
This isn’t about intent. Product managers aren’t ignoring experience, they’re doing their job. Designers and writers aren’t obsessing over craft for fun, they’re trying to prevent problems that compound quietly over time.
This is about incentives. Structure decides what wins when things get tight.
If your system doesn’t protect both perspectives, one will fade. Not all at once, but gradually. You won’t feel it internally, but your users will.
Photo by Vlado Paunovic on Unsplash