Sell Relief, Not Control

For a long time I believed teams adopted our platform because it could express rules their existing tools could not. That was true, and it was not the reason.

The reason was that nobody wanted to be the person responsible if sensitive data leaked.

Think about who was actually adopting. An engineer who had inherited a dataset they never asked for, and a filter file they did not fully understand, written by someone who left two reorgs ago. If it was right, nothing happened and nobody noticed. If it was wrong, it was their name on the commit. They were carrying real personal exposure with no upside at all.

What we sold them, without ever putting it that way, was permission to stop worrying about it.

I know this because it is why I built the thing in the first place. I had that job. I spent hours a day hand-writing access filters on compensation data, and what I wanted was not better security tooling. I wanted to stop being the person holding the risk. So did everyone else.

Governance products fail when they are sold as control and succeed when they are sold as relief.

This is the most portable thing I have learned in twelve years, and it is not really about governance.

Here is the diagnostic. If your feature adds a step to somebody's day, you will push it uphill for years and you will call the problem change management. You will build enablement decks. You will run office hours. You will get an executive to mandate it and watch adoption stall exactly at the boundary of that executive's org. If your feature removes something people are quietly afraid of, they will come and find you, and your problem becomes capacity.

Same feature list either way. What changes is whether anyone shows up.

Which gives you something to test before you build. Find the person who is personally exposed if the rule is wrong and gets nothing if it is right. Not the person who owns the policy on paper — the one who takes the blame. If you cannot find them, you are probably about to build something correct and well-designed that nobody adopts, and you will spend two years believing the problem is education.

It also tells you how to describe your own product. We could have called the platform centralized policy management with fine-grained enforcement. Accurate, and it lands like an obligation. What we said instead was closer to: you will not have to think about this again, and if something changes upstream it will not silently become your problem.

Years later I used the same move on a completely different problem. When I needed teams to care whether their data was ready for the AI agents they were building, the obvious framing was a gate — you may not launch unless you meet this bar. Gates get routed around, and the routing is invisible until something breaks in front of a customer.

So we framed readiness as what it actually delivered to the person doing the work: better evaluation quality, higher developer velocity, lower cost to build a working agent. The requirement was identical. The adoption was not.

None of this is a communications trick. If your product genuinely does not take anything off anyone's plate, no framing will save it, and you should go find the version that does. But most governance products are sitting on real relief and describing themselves as real control, and that is a choice you can simply stop making.

Find what people dread. Build the thing that takes it off them.