Why the Hardest Product Decisions Matter Most

A few years ago, I worked with a team that proudly showed me their dashboard.

It was beautiful. Dozens of metrics, all trending in the right direction. Activation up 12%. Feature adoption up 18%. Time-to-value down by a few precious seconds.

And yet, on my side of the house in Customer Success, the story felt different.

Customers weren’t churning in dramatic waves. They weren’t filing angry tickets. But in calls, I heard a pattern: “We’re not sure which way to set this up.”
“We tried a few approaches.”
“It works… but it’s more flexible than we expected.”

Nothing in the dashboard flagged this as a problem. Everything looked healthy.

That week, I saw three different conversations circulating in our community: a nostalgic reference to Suicide Linux, where a single wrong command could wipe your entire system; an essay about the discipline of tracking fewer metrics over time; and another about how opinionated products drive user success.

They don’t seem related on the surface. But together, they point to something I’ve felt for a long time:

The most important product decisions are the ones that remove options — and they should feel uncomfortable.

In a world where building is faster, testing is easier, and shipping is continuous, we’re getting very good at adding. We’re less practiced at choosing what not to allow.

And that choice — the one that makes a product safer, clearer, more decisive — is rarely reflected in a dashboard.

The Seduction of Flexibility

Early in a product’s life, measuring everything feels responsible. Every behavior might contain a signal. Every feature might unlock a new market.

I understand that instinct. I’ve lived it.

But I’ve also seen what happens when flexibility becomes a substitute for clarity.

One SaaS company I worked with had built a highly configurable workflow engine. You could model almost any process: custom stages, branching rules, dynamic notifications, conditional permissions.

From a design and engineering perspective, it was elegant.

From a customer perspective, it was overwhelming.

Here’s what we saw over six months:

64% of new customers created more than three different workflow configurations in their first 30 days.
Only 27% of those configurations were still active after 90 days.
Support tickets related to “setup confusion” were among the top three categories, despite extensive documentation.

Nothing was technically broken. But people were experimenting their way into complexity.

When we interviewed customers who had successfully adopted the product long-term, a pattern emerged: they had copied a strong template and changed very little.

They weren’t looking for infinite possibility. They were looking for a confident starting point.

Flexibility had been positioned as empowerment. In practice, it was cognitive load.

The Quiet Risk of “You Can Do Anything”

The story about Suicide Linux has always fascinated me. For those unfamiliar: it was a version of Linux that would execute commands exactly as typed — including catastrophic ones. Type a command that deletes your root directory? It would comply.

It was, in a way, pure.

No guardrails. No second chances.

Most modern products sit at the opposite extreme. We add confirmations, undo states, safety nets, auto-saves. We design to prevent irreversible damage.

But here’s the tension: removing destructive power is a product decision. So is removing unnecessary complexity.

Both are forms of protection.

In Customer Success, I’ve seen two kinds of risk:

Destructive risk — where a user can break something critical.
Diffusive risk — where a user can build something so complex or misaligned that it slowly erodes value.

We’re usually vigilant about the first. We test race conditions. We implement synchronization barriers. We prevent edge-case failures.

But the second kind? It hides in plain sight.

It shows up as:

Accounts that technically “use” the product but never scale.
Features that are adopted but not integrated into core workflows.
Renewals that stall because the product feels heavier than expected.

No single event triggers an alarm. There’s no catastrophic command. Just gradual dilution.

And because nothing explodes, we don’t always treat it as urgent.

The Discipline of Fewer Metrics — and Fewer Paths

There’s a growing conversation about tracking fewer metrics over time — about moving from measuring everything to focusing on what truly signals durable value.

I’d argue we need the same discipline in our product surfaces.

In one organization, we decided to run an experiment: instead of presenting customers with five different onboarding paths based on persona, we collapsed them into two.

This felt risky. What if we alienated edge cases? What if conversion dipped?

Here’s what happened over the next quarter:

Onboarding completion increased by 15%.
Time-to-first meaningful action decreased by 22%.
Support tickets related to “which path should I choose?” dropped by nearly half.

We didn’t add functionality. We removed ambiguity.

The most telling moment came during a follow-up interview. A customer said:

“I liked that you didn’t ask me to decide everything upfront. It felt like you knew what most teams need.”

That sentence stayed with me.

We often think respect means giving people full control. But sometimes respect looks like saying, “We’ve seen this before. Start here.”

This is what opinionated products do well. They encode experience into defaults.

And yes, they exclude some possibilities.

That exclusion is the point.

Where Career Growth and Product Maturity Intersect

Another trend I’ve noticed lately: product leaders talking about ditching the “perfect roadmap.” About reframing product management as professional translation. About building in public and forcing hard integration decisions.

Underneath all of it is a shared realization: clarity requires trade-offs.

In my early years in Customer Success, I thought my job was to advocate for every request. If three customers asked for a feature, I felt urgency. If ten asked, I felt pressure.

Over time, I learned to listen differently.

Not just what they asked for — but why.

Often, feature requests were proxies for:

Confusion about existing functionality.
Misalignment between their internal process and our mental model.
A desire for validation that they were “doing it right.”

When we fed every request into the roadmap, we created a product that tried to be everything to everyone.

When we paused and asked deeper questions, we sometimes made harder calls:

Saying no to customization that would fragment the core experience.
Simplifying configuration even when power users wanted more toggles.
Standardizing workflows to protect long-term scalability.

Those decisions were uncomfortable in the short term.

But here’s what the retention data showed over two years: accounts that adopted our standardized workflows had a renewal rate 18% higher than those using heavily customized setups.

Not because customization is inherently bad — but because coherence compounds.

Making the Hard Choice Visible

One of the challenges in all of this is that removal doesn’t demo well.

You can’t easily celebrate the feature you decided not to build. There’s no launch post for the configuration option you eliminated.

And yet, in mature products, the absence of chaos is often the most intentional design choice.

So how do we practice this kind of discipline more consciously?

Here are a few questions I’ve started asking in roadmap and feedback reviews:

If we add this, what decision are we avoiding?
Sometimes a new feature is a way of postponing a harder simplification.
Does this increase the number of meaningful paths — or just possible ones?
More paths aren’t inherently better. The question is whether they lead somewhere durable.
Who benefits most from this flexibility — new users or experienced ones?
Early-stage confusion is far more expensive than late-stage constraint.
What will Customer Success need to explain repeatedly if we ship this?
Repetition in support and onboarding is often a signal of product ambiguity.

These aren’t anti-growth questions. They’re alignment questions.

Because when products scale, inconsistency scales with them.

The Courage to Decide

There’s something quietly brave about building guardrails.

It requires trusting your understanding of users. It requires saying, “We’ve learned enough to narrow this.” It requires accepting that you might lose a few edge cases to serve the majority more clearly.

As someone who spends her days listening to customers — their frustrations, their aspirations, the messy reality of their operations — I’ve come to believe this:

People don’t actually want infinite possibility.

They want momentum. They want confidence. They want to feel like the product is steady beneath them.

When we make hard decisions — fewer metrics, fewer onboarding paths, fewer toggles — we’re not limiting them. We’re reducing the surface area of doubt.

And in that reduction, something powerful happens: adoption becomes less about experimentation and more about progress.

In a world that celebrates speed and expansion, choosing constraint can feel countercultural.

But sometimes the most responsible thing we can do as product builders is this:

Not to prove we can build anything.

But to decide, carefully and visibly, what we won’t.

Because the product decisions that should be hard?

They’re usually the ones that protect the people using it every day.