Usage Is Not Adoption Until It Can Survive Disclosure

A user can find a product valuable and still avoid admitting that they use it. For product teams, that distinction matters more than it first appears.

The current debate around AI watermarks makes this visible. Some people object because a watermark could expose that AI was used for work or study. At the same time, AI companies describe the broader backlash as a problem of trust, while product teams continue to ask whether anyone is actually using agents and why apparently useful AI products fail.

These are not separate issues. Together they point to a gap in how we measure adoption.

Most product dashboards treat usage as positive evidence. An active user generated something, completed a workflow or returned the next week. That tells us the product supplied utility. It does not tell us whether the usage is accepted by the user’s employer, customer, teacher, colleagues or even the user themselves.

I would call the missing condition permission. Not permission in the narrow legal sense of clicking accept, but practical permission to use the product openly.

This is particularly important in B2B. Imagine an employee using an AI tool to prepare a customer proposal. The output saves time and the employee returns every week. By conventional measures, adoption looks healthy. But if they remove traces of AI use, avoid discussing the tool with their manager and copy the output through an unapproved personal account, the company does not have durable adoption. It has hidden utility.

Hidden utility is still useful evidence. It shows that a real job can be done better. But it is also fragile. A policy change, security review, public mistake or new manager can remove that usage immediately. The product has entered the task without entering the organization.

This is where product strategy and metric design need to meet. Teams should not only ask whether people use the product. They should ask whether usage survives disclosure.

Can a user explain how the output was produced? Can a manager approve the workflow without creating an exception? Can security review the data flow? Can colleagues inspect or challenge the result? Will the user keep using the product when its involvement is visible?

I do not think this requires another large dashboard. Metric sets already become noisy because teams add measures more easily than they remove them. A few targeted experiments are more valuable. Make AI involvement visible for one workflow and observe whether completion and repeat use hold up. Ask users to share an AI-assisted result with a colleague rather than keeping it private. Test an approved team workspace against individual accounts. Track whether a successful personal habit becomes a supported team process.

The same logic applies beyond AI. Recommendation algorithms can shape physical products before users consciously ask for those changes. A beta can reveal that customers value an unexpected feature while the business is not prepared to support it. A team can move quickly and still create a way of working that people cannot sustain. In each case, observed behaviour is only the start. Product leaders have to establish whether that behaviour can become an explicit, supported part of the system.

This also changes roadmap choices. If users already get value but hide their usage, building more capability may be the wrong next step. The better investment may be administration, review controls, policy templates, team-level visibility or clearer boundaries around acceptable use. Those additions may look less exciting than another model improvement, but they convert private utility into organizational adoption.

I have learned to be careful when a product appears to spread faster than the organization can acknowledge it. That can look like strong pull. Sometimes it is. But until people can use the product openly, the growth is sitting on borrowed permission.