Does anyone really want infinite optionality?

At 8:07 am the Product Manager sat with their second coffee, staring blankly at the feature flag matrix. Fourteen toggles active. Fourteen. Each one representing a path not taken. Or worse, a path left open, dangling in limbo. “We’ll let the users decide”, they had said in the last sprint planning. But now, looking at this dense cluster of switches and conditional logic, they weren’t so sure. Was anyone really deciding anything? Or were they just being left alone in the forest without a trail map?

It’s a weird thing, this obsession with optionality. On paper, it sounds empowering. “Don’t make assumptions for the user.” “Let them customise their experience.” “Flexibility is a feature.” And it is. Sometimes. But more often than not, it’s a comforting illusion. Something we reach for when we’re too afraid, too uncertain, or just too tired to take a stance.

People love the idea of choice until they’re standing in front of the wall of 32 ice cream flavours. Strawberry or wild berry? With or without chunks? Dairy-free, low-sugar, oat-based, organic, all of the above? Suddenly it’s not fun anymore, it’s homework. Now imagine trying to make that decision in the middle of your workday while also answering Slack messages and half-listening to a Zoom call. That’s what digital optionality feels like in practice. Exhausting.

And it doesn’t stop with users. Engineers suffer, too. Every extra branch in the logic is another test case, another support scenario, another possible bug. Multiply that by the number of active users and the number of environments, and you’ve got a maintenance nightmare in the making. PMs get stuck in the same trap, trying to test every possible combination, explain every scenario in documentation, anticipate every permutation. It’s the death of velocity, disguised as empathy.

The worst part? We do it with good intentions. We say “We don’t want to be too opinionated.” But that often just means: we don’t want to be wrong. So we punt the decision to the user. “Let them choose,” we tell ourselves. “We’re empowering them.” But ask any real human who’s not steeped in Product-speak, and they’ll tell you: most of the time, they don’t want to choose. They just want the thing to work. Make it clean. Make it smart. Get out of the way.

There are places where choice is critical, make no mistake. Accessibility settings, for one. Give users control over how they consume content, interact with interfaces, or accommodate physical or cognitive needs. Language and regional settings? Also yes. Cultural nuance matters. And then there’s the domain of power users, the ones who do want to tweak, script, automate, fine-tune. Give them hooks, but don’t make them prerequisites. That’s the difference between empowering and abandoning.

When Product teams leave everything open-ended, they’re not building for people, they’re building for edge cases first. And that’s rarely the right starting point. Defaults aren’t just conveniences; they’re statements. They say “We thought this through. We made a call. Try it this way.” When you default well, you don’t have to beg for feedback, it finds you. If the default doesn’t work, someone will tell you. Then you can listen. Then you can fix it.

Some of the best tools out there, from Notion to the Apple ecosystem, thrive on opinionated design. They don’t ask you fifty questions on first open. They give you something coherent out of the gate. There’s clarity in that. There’s trust. Users don’t come to software hoping to co-create design. They come to get something done. Optionality can support that, but it shouldn’t become the entire experience.

So what should Product teams be doing instead? Start with a strong hypothesis. Take a position. Build for the majority first, and do it with conviction. Ship with defaults that reflect real use cases. Give users escape hatches where it matters, but don’t hand them the keys to the engine room on day one. Then, and only then, watch what happens. Look at the data. Listen to the weirdly specific support tickets. Pay attention to the workarounds. That’s where iteration lives.

And yes, you’ll hear from edge cases. That’s not failure. That’s signal. The goal isn’t to preempt every complaint, it’s to build something coherent enough that the outliers are obvious and instructive. Not everything has to be a setting. Sometimes the right response is: “We chose this way for a reason. Tell us if it’s not working for you.” That balance between humility and authority is what defines good Product leadership.

Too much choice, paradoxically, is a form of neglect. It says, “We didn’t want to be wrong, so we made you decide.” But decision-making is a burden, and most people already have enough on their plate. Good Product design doesn’t just work, it relieves people. It gives them back their focus, their time, their mental clarity. Fewer toggles. Fewer dead ends. Fewer moments where the user sighs and thinks “Why do I have to figure this out?”

Back to that feature toggle matrix. It didn’t need fourteen switches. Maybe three of them were critical. Maybe five were experiments in disguise. The rest were fear made manifest. Of being wrong, of complaints, of assuming too much. But Product work isn’t about being perfectly right. It’s about having a strong point of view and the willingness to change it once the evidence tells you to.

So no, people don’t really want infinite optionality. They want clarity. They want care. They want products that feel like someone made thoughtful decisions on their behalf, and left the door open just wide enough for them to tweak what really matters. The rest is our job.