What enterprise customers mean when they ask for “more control.”

If you work on enterprise software for long enough, you will hear the same request in a dozen different forms. “We need more control.” “Can we configure this?” “Our admins want to be able to turn that off.”

The obvious response is to add settings. A toggle here, a permission there, an admin panel that grows a little every quarter. Each addition is reasonable on its own. Together they produce a product that is harder to understand, harder to test and — ironically — harder to control.

“Control” is usually a symptom

When I dig into these requests, the underlying need is rarely the setting itself. It is usually one of three things:

• Predictability. “Something changed and we didn’t know it was going to.” The customer wants to know what will happen before it happens.
• Visibility. “We can’t tell who did what, or why.” The customer wants an audit trail they can show to someone else.
• Recoverability. “If this goes wrong, we’re stuck.” The customer wants a way back.

None of these is solved by a toggle. A toggle lets an admin prevent a behaviour, which is the bluntest possible answer to “I’m worried about this behaviour.”

Ask what went wrong last time

The most useful discovery question I know for this situation is: “Tell me about the last time this caused a problem.”

The answer almost always reveals a specific moment — a release that changed a workflow without warning, a bulk action nobody could undo, a report that didn’t match what the finance team expected. That moment is the real requirement. The request for control is the customer’s best guess at a solution.

Customers are experts in their problems. They are not obliged to be experts in our solution space.

Better answers than another setting

Once you know the moment, the options widen:

• Preview before commit. Show what a bulk change will do before it runs.
• Change communication. Release notes, in-product notices and a predictable rollout calendar solve a surprising number of “control” requests.
• Audit history. A clear record of who changed what, and when, gives admins confidence without restricting anyone.
• Undo. A reliable way back is often worth more than a way to prevent.

Sometimes a setting really is the answer — regulated industries have genuine constraints, and some behaviours should be configurable. But it should be the conclusion of discovery, not the default.

Why this matters for the roadmap

Every setting is a permanent commitment. It has to be documented, supported, tested in combination with every other setting and migrated in every future redesign. A product that answers every “more control” request with a toggle slowly becomes a product that nobody — including its own team — fully understands.

Solving the confidence problem underneath is harder up front. It needs better discovery, closer work with support and sometimes a less exciting roadmap item. But it compounds: customers trust the product more, the admin panel stays small, and the next request starts from a better place.