When Product Defaults Become User Decisions

A few weeks ago, a customer wrote into our support queue with a screenshot and a single line of text: “When did this become mandatory?”

They weren’t angry. Just tired.

We had added a new step to our onboarding flow—an account connection that used to be optional. Internally, it made perfect sense. It improved attribution, enabled smarter automation, and fed our analytics layer with cleaner data. In the experiment doc, it was described as a "low-friction requirement." In the customer’s day, it was one more hoop.

That message has been echoing in my head as I’ve watched this week’s conversations unfold. Windows 11 users frustrated by Microsoft account requirements creeping into everything. Product managers debating interviews versus A/B testing. AI teams questioning whether accuracy is even the right KPI.

Different threads. Same tension.

At some point, the default becomes the decision. And when it does, users feel it immediately.

Not as a feature. Not as a metric. But as a shift in who the product is really optimized for.

The Creep Is Never Sudden

No one wakes up and decides to make a product more annoying.

The Windows account debate is a good example. Requiring a Microsoft account to install or fully use Windows 11 likely looks rational from inside the company. Centralized identity improves security. It enables cloud backups, device sync, and subscription upsells. It standardizes the ecosystem.

From a systems perspective, it’s elegant.

From a user’s perspective—especially someone who just wants a local machine—it feels like something is being taken away.

What fascinates me about these moments is that the shift is usually incremental. A nudge here. A requirement there. An optional step that becomes “recommended.” A recommended step that becomes mandatory.

Individually, each change feels defensible. Collectively, they reshape the relationship.

In customer success, we see this pattern play out long before it becomes a headline. It shows up as:

A spike in tickets after a “minor” onboarding update
Customers asking how to bypass a new step
Quiet churn from accounts that never quite activated

And often, the internal metrics still look fine. Conversion is stable. Feature adoption is up. The experiment shows statistical significance.

But something more subtle has shifted: the product is now optimizing for internal coherence over user autonomy.

Those are not always the same thing.

When Metrics Become Mandates

Another thread this week asks whether accuracy is the wrong KPI for AI products. It’s a question I’m grateful more teams are asking.

Accuracy feels safe. Quantifiable. Improvable.

But I’ve seen AI features that were technically 95% accurate—and still deeply frustrating to customers. Why? Because the 5% failure cases were high-stakes moments. Because users didn’t understand why something happened. Because correcting the system took longer than doing it manually.

According to a 2023 McKinsey survey, 40% of organizations report that AI initiatives fail to deliver expected value—not because the models don’t work, but because adoption lags. The system performs; the humans hesitate.

That gap is rarely about raw performance. It’s about perceived alignment.

Similarly, in product experimentation, we often treat A/B test wins as moral victories. The variant with the higher click-through rate survives. The rest is discarded. But as anyone who has sat through real customer interviews knows, behavior is not always endorsement.

I’ve watched users click the “primary” button simply because it was visually dominant—then tell us in conversation that they felt rushed or confused.

A lift in CTR is not the same as clarity.

An increase in account linkages is not the same as consent.

An improvement in model accuracy is not the same as trust.

When we allow a metric to graduate from signal to mandate, we risk turning a local optimization into a global constraint.

And that’s when defaults harden.

The Hidden Cost of “Just One More Requirement”

There’s a reason these changes spark disproportionate reactions.

Requirements accumulate in ways benefits do not.

Each additional mandatory step introduces three invisible costs:

Cognitive cost – The user has to understand what’s being asked and why.
Emotional cost – The user has to decide whether they’re comfortable complying.
Future cost – The user has to consider the downstream implications.

Individually, these costs are small. Together, they shape the overall feeling of a product.

The Baymard Institute reports that 22% of US online shoppers abandon carts because the checkout process is too long or complicated. Not broken. Not insecure. Just too much.

And yet, in roadmap discussions, each new requirement is justified with its own clean rationale:

“We need this data for personalization.”
“This improves long-term retention.”
“It’s better for security.”

All reasonable. All true.

But customers don’t experience them separately. They experience them as a stack.

One of our mid-market customers recently downgraded after two years. In the exit call, they didn’t cite pricing or missing features. They said, “It just feels heavier than it used to.”

Heavier.

Not wrong. Not broken. Heavier.

That word has stayed with me because it captures something metrics rarely do: the cumulative weight of decisions that made sense in isolation.

Interviews, Experiments, and the Question Beneath the Question

There’s an ongoing debate about customer interviews versus A/B testing—as if they are competing philosophies rather than complementary tools.

Here’s what I’ve learned sitting between product and customer conversations for years: experiments tell you what people will tolerate. Interviews tell you what they value.

Both matter. But they answer different questions.

When we changed that onboarding step from optional to mandatory, the A/B test showed a modest increase in connected accounts. Activation improved by 3.8%. On paper, a clear win.

But in follow-up interviews, customers used language like:

“I felt pushed.”
“I wasn’t ready for that yet.”
“I wanted to explore first.”

The tension wasn’t about the feature. It was about timing and agency.

We eventually redesigned the flow so the connection was required—but contextualized. We explained what it unlocked, showed a preview of benefits, and allowed exploration before commitment.

The metric gain remained. The support tickets dropped by 27% over the next two release cycles.

The difference wasn’t the requirement itself. It was whether users felt like participants or passengers.

The deeper question isn’t “Does this improve our KPI?” It’s “Who does this primarily serve?”

When the honest answer is “us,” that’s not inherently wrong. But it should make us pause.

Designing With Power in Mind

As products mature, they accumulate power.

Power to set defaults. Power to define flows. Power to decide what’s mandatory.

With AI, that power extends further—into recommendations, automation, even decisions made on a user’s behalf. The Netflix design exercise circulating this week captures this well. Improving recommendations isn’t just a modeling problem; it’s a power problem. What gets surfaced? What gets buried? Who shapes taste?

Defaults are persuasive. Research from the University of Chicago found that opt-out organ donation policies result in participation rates above 90%, compared to under 20% in opt-in systems. The choice architecture alone changes behavior dramatically.

In product design, we wield that same influence daily.

So the question becomes: Are we using defaults to reduce burden—or to increase compliance?

The difference is subtle but critical.

Reducing burden looks like:

Pre-filling information users would otherwise enter repeatedly
Remembering preferences transparently
Suggesting next steps that align with stated goals

Increasing compliance looks like:

Hiding skip options
Making opt-outs obscure
Requiring accounts for actions that don’t strictly need them

Both may drive engagement metrics. Only one strengthens the relationship.

As a Customer Success Lead, I live in the aftermath of these decisions. When a default overreaches, it’s rarely framed as a philosophical issue. It shows up as confusion, resistance, or churn.

People don’t articulate it as “misaligned incentive structures.” They say, “This feels like too much.”

And they’re usually right.

A Practical Pause Before You Ship

I’m not arguing for fewer requirements across the board. Security matters. Data matters. Cohesion matters.

But I do believe we need a consistent pause before turning an option into a mandate.

Here’s the checklist I now quietly run—learned the hard way:

Is this requirement primarily solving a user problem or a company problem?
If it’s the latter, have we been transparent about that tradeoff?
What would happen if we delayed this step?
Does it truly need to happen upfront, or are we optimizing prematurely?
Have we tested not just behavior, but sentiment?
What language do users use when describing this moment?
What cumulative weight are we adding?
How many “small” additions have we shipped in the last year?
If we were starting fresh today, would we design it this way?
Or is this an artifact of internal systems layering over time?

These questions don’t slow teams down. They sharpen decisions.

In my experience, the strongest products aren’t the ones with the most integrated ecosystems or the highest model accuracy. They’re the ones where users feel a sense of alignment—where the defaults feel like help, not leverage.

The Relationship We’re Actually Designing

When users push back against account requirements, or question AI decisions, or bristle at creeping constraints, they’re not rejecting technology. They’re responding to a shift in relationship.

Every requirement communicates something.

It says:

“We need this from you.”
“We know what’s best.”
“This is the price of entry.”

Sometimes that’s fair. Sometimes it’s necessary.

But the more power our products accumulate, the more intentional we must be about how we exercise it.

Because in the end, customers don’t evaluate us feature by feature. They evaluate us by feel. By whether the product seems to expand their agency or quietly narrow it.

That email—“When did this become mandatory?”—wasn’t really about a single step.

It was about noticing the moment when the default stopped feeling like assistance and started feeling like control.

And if we’re honest, those moments are rarely accidents. They’re the outcome of a hundred small, reasonable decisions that no one stopped to examine together.

The work isn’t to avoid making hard calls. It’s to remember that every default is a statement about who the product ultimately serves.

If we can keep that question alive—especially when the metrics look good—we build something sturdier than growth.

We build alignment.

And in my experience, alignment is the only default that compounds.