dansauvé.com

Recent thoughts

Why Shipping Faster Quietly Degrades Product Experience

March 31, 2026

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

Introducing Craft & Systems

February 27, 2026

At the end of 2024, I did something I had not done in 25 years: I started blogging again. The last time I wrote consistently online was around the turn of the millennium. Back then it was pure experimentation (and mostly teen angst, honestly). A personal site, some thoughts, some code, and a lot of curiosity. Then life and career took over.

Fast forward to late 2024 and I was working at a web hosting company. We were building tools for people who publish on the web, and it felt wrong not to be using the product myself—if you build for creators, you should create. So I spun up this WordPress site you’re reading now.

My goal was more pragmatic than passionate: reacquaint myself with WordPress, understand user experience, and live in the product. WordPress has changed little at its core over the years. Posts, pages, and themes still work much the same way they did when I was building client sites in the mid-aughts. The muscle memory came back quickly.

Within a weekend I had the basics in place, and I even had an old design ready to go. The HTML and CSS had been sitting in a folder on my NAS since 2005! I was surprised at how well it held up. A layout I had coded years ago and never shipped worked in modern browsers with minimal adjustment. The site was essentially done, so I wired it up, tweaked a few things, and published my first post.

From there I set a simple target: one post per month. It felt sustainable and frequent enough to create a signal, yet infrequent enough to fit into my life. I did not want noise. I wanted intention.

Over the course of the year something interesting happened: my writing began to converge around a theme. The posts that felt most natural were about design, product management, and leadership. They were grounded in experience, not theory. I found myself clarifying what I believe about craft, systems, teams, and decision making.

I also wrote personal pieces. A few pet peeves. Observations that had nothing to do with design. They were fun, but they diluted the signal.

That tension led to a decision.

Today I am launching a new blog: Craft & Systems. It is where I will publish more regularly about design and software leadership. Focused and opinionated, but grounded in practice. I have migrated my design and product leadership posts there so they can live together as a coherent body of work. If that is the kind of writing you come here for, take a look and consider subscribing to my newsletter.

Publishing here will likely be more sporadic as I put more energy into Craft & Systems, but it will not disappear. This space will remain my personal outlet for the desk gadget posts, the occasional rant, all the things that do not quite fit into a professional throughline, but I still want to write about.

In some ways, this feels like a return to 1999. A personal corner of the web that is mine. Just more intentional about where different ideas belong.

Thanks for reading then, and now.

Org Design Is a Living System

February 25, 2026

Most organizations treat org design as an event. A reorg happens, reporting lines shift, teams are restructured, a new operating model is presented, and there is a short period of optimism. Clarity feels higher. Energy spikes.

Then, gradually, familiar friction returns. Decisions slow, ownership blurs, process thickens. Strong individuals compensate quietly, and within a year or two, another structural adjustment is proposed.

The pattern repeats because org design is being treated as a static solution instead of what it actually is: a living system.

If you want sustained product velocity in an enterprise environment, three elements have to reinforce each other continuously: structure, process, and people. Structure defines how accountability flows. Process translates that structure into daily behaviour. People bring judgment, capability, and discipline to both. When those three pillars align, execution feels coherent. When they drift apart, even talented teams struggle to move decisively.

The difficulty is that you cannot optimize any one of them in isolation.

Clarity Before Process

Structure is the least understood of the three. It is often mistaken for reporting lines or titles. In reality, structure is about decision boundaries. It determines who can make which decisions without escalation, who owns trade-offs across domains, and who carries accountability when commitments are not met. In complex enterprises, specialization introduces layers of shared services, platform teams, architectural governance, compliance oversight, and enablement functions. Each layer serves a purpose. But if decision rights are not clearly defined across them, work begins to depend on negotiation rather than judgment. Designers hesitate to converge because direction may shift. Engineers delay irreversible decisions because scope feels unstable. Product managers escalate instead of decide because ownership is unclear.

Ownership Before Methodology

When that happens, organizations tend to reach for process as a corrective measure. More alignment rituals. More planning checkpoints. More documentation. A new methodology. But process cannot compensate for structural ambiguity. It can only mask it temporarily. If accountability is diffused, no framework will restore decisiveness. Agile will become ceremony. Shape Up will become theater. Quarterly planning will become slide production. Process works only when it reinforces clear decision boundaries.

Capability Before Headcount

People are the third pillar, and the most dynamic. Concentrated accountability requires individuals who are comfortable exercising judgment under uncertainty. Product leaders who are willing to narrow scope and stand behind trade-offs. Engineering leaders who can engage in tension without defaulting to escalation. Designers who can converge and commit rather than endlessly explore. The wrong person in the right structure will hesitate. The right person in the wrong structure will burn out trying to compensate. Talent alone does not fix misalignment. Nor does structure compensate for weak ownership instincts. The system only holds when the behaviours match the design.

This is where the real complexity of org design emerges. Leaders often ask where to begin. Should we restructure first? Redefine the planning process? Hire differently? The honest answer is that there is no clean starting point. You have to stack it from both sides. You clarify decision boundaries while simultaneously ensuring the people inside those boundaries are capable and willing to operate with real accountability. You evolve process while pressure-testing whether it reflects how decisions actually move. It is iterative, not sequential.

And even when you achieve alignment, it does not stay aligned.

Maintenance Before Reinvention

Like any system, an organization requires lubrication.

People join. People leave. Teams expand. Mandates shift. Informal norms evolve. The clarity that once felt obvious becomes assumed. What was debated openly becomes tribal knowledge. New members are handed documentation and told, “this is how we work,” but documentation is not the system. Behaviour is the system.

If onboarding treats process as static instruction rather than lived practice, drift begins immediately. New hires interpret decision boundaries differently. They replicate habits from prior organizations. They test edges of authority. Without deliberate reinforcement, structure and process quietly degrade.

The same is true when experienced leaders depart. They carry implicit context about how trade-offs are resolved and where accountability truly sits. If that context is not re-articulated and validated, ambiguity creeps back in. Over time, more meetings appear. Escalation paths lengthen. Process thickens again.

Managing the process requires a process. There must be disciplined moments where teams revisit how they operate. Not to reinvent the model constantly, but to recalibrate it. To ask whether decision boundaries are still clear. Whether load is appropriate. Whether rituals still serve their intent. Whether accountability is concentrated or quietly diffused. This maintenance is rarely glamorous. It does not produce dramatic before-and-after slides. But without it, entropy wins.

The organizations that sustain velocity are not the ones that found the perfect structure. They are the ones that treat org design as ongoing stewardship. They understand that structure, process, and people are interdependent. They recognize that growth will test clarity. They accept that friction is a signal to adjust, not a reason to layer more ceremony.

There is no universally correct org model. Centralized functions can work. Embedded teams can work. Platform-heavy structures can work. What matters is coherence across the system and the discipline to maintain it. A simple structure with clear accountability will outperform an elegant one with blurred boundaries. A lightweight, co-created process will outperform an industry-standard framework that does not fit reality. Focused leaders with real ownership will outperform overloaded coordinators inside sophisticated org charts.

Build the System You’re Willing to Maintain

Org design is not a one-time act of architecture. It is a continuous act of maintenance. It requires leaders to revisit uncomfortable questions about ownership and authority. It requires investing in people who can carry concentrated accountability. It requires resisting the temptation to declare the model complete.

The goal is not stability for its own sake. It is coherence under change.

When structure supports process, process supports people, and people actively maintain the system, execution compounds. Decisions accelerate. Trust deepens. Shipping becomes more predictable. And the organization adapts without needing a reorg every two years.

Photo by Nathan Kelly on Unsplash