This morning I had to leave home while our new cleaning staff was still working.
I could have stayed around and kept an eye on things. After all, I don’t know them well yet.
Instead, I locked one of the rooms, told them about it, and left.
They had access to everything they needed to do their job. I had protected the one space they didn’t need access to. When they finished, they would close the main door behind them.
No supervision. No awkwardness. No need to make a judgement about whether I could trust them.
That got me thinking about the difference between low trust and zero trust.
Low trust says: I don’t trust you, so I need to watch you.
Zero trust says: I don’t need to trust you, because I’ve designed the system so that you don’t have access to what you don’t need.
That’s a much better experience.
We see the opposite approach all the time in products and organisations.
At one of the large enterprises I worked with, I remember encountering workflows where, instead of giving people sufficiently granular permissions, the system relied on email approvals from the HOD for all sorts of things.
The implicit logic was: We don’t trust you to do this, so get someone senior to approve it.
But the HOD wasn’t necessarily adding judgement. Often, they were simply acting as a human permission layer because the system itself wasn’t capable of expressing the required boundary.
That’s low-trust design.
And it creates what I think of as a pipe.
The work goes from person A to person B, not because person B needs to do anything meaningful, but because the system hasn’t been designed well enough to let person A proceed safely.
Once that pipe exists, everyone starts working around it.
Approvals become rubber stamps. Work waits for people who have no context. Managers become bottlenecks. People optimise for getting approval rather than making good decisions.
And eventually, someone calls it a process problem.
It wasn’t a process problem.
It was a product design problem.
The better question is not, “How do we make sure this person doesn’t do something they shouldn’t?”
It’s:
“What exactly are we worried they might do, and can we design the system so they simply can’t do it?”
That’s the essence of zero trust.
Assume every request might be risky. Give each person or process only the access it actually needs. Verify what matters. Contain the consequences when something goes wrong.
And crucially, make the system carry the burden of that uncertainty, not the user.
That’s why zero trust can actually produce a more trusting experience.
A well-designed system can be extremely sceptical underneath while feeling remarkably effortless on the surface.
Your bank can continuously assess transaction risk without asking you to prove your identity every thirty seconds.
A workplace can restrict what an employee can access without requiring a manager to approve every action.
A product can make important actions reversible instead of protecting users from every conceivable mistake with another warning or confirmation.
The same principle applies beyond security.
Don’t solve a trust problem with surveillance when you can solve it with boundaries.
There is a fundamental difference between saying “I don’t trust you” and saying “You don’t need access to that.”
The first creates friction.
The second creates clarity.
And perhaps this is one of the underrated jobs of product design: not figuring out whom we can trust, but designing systems where trust becomes less necessary.
Which brings me to the simplest version of the idea:
Trust the process, after designing it well.
Trust shouldn’t be a leap of faith we ask people to make.
It should be the confidence that emerges when the boundaries, permissions and failure modes have been thought through properly.
The best systems don’t require us to constantly watch people.
They make it safe enough to look away.
–
Working through a similar product challenge?