Forced Adoption Produces Bad Product Evidence

When a company makes a feature difficult to refuse, its adoption numbers become less useful.

This matters now because more products are moving from optional to unavoidable. Platforms are putting more value behind accounts. Employers are introducing AI tools into existing workflows. Software companies are adding agents to products their customers already pay for. At the same time, users and companies are becoming more cautious about privacy, security and how their data is used.

The common product response is to treat resistance as friction. Remove the skip button. Make the new experience the default. Require login. Ask administrators to switch it on for everyone. Then point to the increase in usage as evidence that the decision worked.

I think that is a measurement mistake.

If an employee has to use an AI assistant to complete a required process, usage does not prove preference. If a customer must create an account to access something that was previously open, registrations do not prove additional value. If an agent is automatically added to a workflow, activity does not tell us whether the customer trusts it. The metric has changed because the choice architecture changed, not necessarily because the product improved.

This is especially dangerous when teams use those numbers to set strategy. A roadmap based on forced adoption can look evidence-driven while being built on weak evidence. The team sees activation rising and invests further. Sales includes the feature in every package. Operations adapts around it. Six months later, the organization discovers the resistance elsewhere: lower task completion, more manual workarounds, blocked integrations, support complaints or customers leaving without clearly explaining why.

Churn research often finds signals that were invisible in the active customer base. Refusal can provide those signals earlier, but only if the product allows refusal to be expressed clearly.

I would rather give users a specific way to say no than make them invent one. Let them decline an AI-generated recommendation. Let an administrator block an agent for a defined reason. Let a visitor understand what an account changes before requiring registration. Ask one short follow-up question, with answers such as data policy, accuracy, workflow fit or lack of value. Do not turn it into an interrogation, and do not punish the choice by breaking unrelated parts of the product.

That creates a much better input for product decisions. A high refusal rate caused by security policy requires a different response from one caused by poor output quality. A feature rejected by experienced users but accepted by new users may have a positioning problem, or it may be removing control that experts need. A login rejected because it offers no visible benefit is not the same problem as a login rejected because customers distrust the data practices behind it.

This also clarifies responsibility across the team. Product decides what choice is offered. Design makes the consequences understandable. Engineering ensures the old path remains safe where appropriate. Legal and security define real constraints rather than vague warnings. Growth measures voluntary adoption separately from required use. Leadership decides whether mandatory use is justified, but should not call it customer validation.

Not every product decision can be optional. Companies can standardize tools, retire old systems and require controls for legitimate operational reasons. But when use is mandatory, I would measure whether the required task becomes faster, safer or more reliable. I would not use usage itself as proof of value.

Good product management depends on distinguishing behavior from intent. Removing the ability to refuse may improve a dashboard in the short term, but it removes one of the clearest signals a customer can give. If I want evidence strong enough to shape a roadmap, I need to preserve the conditions under which users can disagree with me.