When I am brought in to lead the experience of a product or feature, I like to start by inviting everyone to share in the vision I have outlined, which is often an accumulation of their many individual ideas, aspirations, and strategies to achieve particular business outcomes. This is where we dream of the ideal state without immediate technology limitations attached, so everyone in the room can see how the experience will enable its users, build their trust, and deliver unique value.
This part frequently goes well. People can imagine themselves and others using the product, and we often end with everyone in alignment. We break and leave excited.
Then the real work starts, and all of us who agreed on that vision must meet to negotiate what P0 will include. What ships first on the way to our vision? How does each milestone inform and enable the next?
In my nearly 20 years of product design, this conversation almost always focuses on features and functionality that are hoped to drive adoption. What should this product do? What jobs will it enable? What use cases does it cover? This is the wrong lens. Instead, the conversation must start from “what will bring people back to us, and trust us to enable them over any competing product?”
It’s understandable that these conversations go so predictably. Debating whether a product or feature has enough reason for being is an exercise in validating its existence at all, and making a business case for attention and resourcing. The people asking it aren’t being short-sighted on purpose. They’re looking out for the interests of the business, and it’s a good question. It’s also focused only on the immediate impact.
More often than not, these conversations end here. At an articulation of value delivery. Not trust building. Not adoption. Those discussions come later, and are often backed into by flexing feature definitions, or worse, by hoping an “amazing experience” will be differentiating enough to win customers.
This simply doesn’t work.
By used I mean handed work that matters, frequently, and without constant oversight or rework.
Value delivery wins for a reason that has nothing to do with conviction. It has a number attached to it. Trust doesn’t. So the trust work is never debated, but instead omitted entirely.
Building for retention is simple product thinking, with roots long before agents. Building a well-functioning product is not enough. You need users to want to use your product, and to trust it with high-value workflows.
Agents and agentic platforms have made the consequences worse. The entire conversation around them is a capability conversation. What use cases do they solve? What workflows do they support? What data do they have access to? How do they interact with other agents and tools? Very little of it is about how we build trust. Almost all of it is about demonstrating value quickly enough that people adopt the thing at all.
A release that delivers value can create adoption. It won’t create retention, and it certainly won’t create advocacy.
I have watched this happen to me. Most of my experience as a user is with tools that claim to take a designer from design to code. I’ve used Vercel, Figma Make, Builder.io, and of course Claude Code with Anthropic’s models. Every one of them is capable, and I still won’t let any of them work unsupervised.
The test I give them is deliberately easy to grade. I start from a tangible piece of design and ask the tool to build it verbatim. Design output is usually judged subjectively, but when I hand over a finished frame and ask for a faithful copy, the judgment is objective. It matches or it doesn’t.
They all get close. None gets close enough that I’d delegate more than a single task. Stacking tasks is out of the question.That last part isn’t me being cautious. It’s arithmetic. If I hand an agent a stack of tasks and the outputs come back substandard across all of them, I’ve created more work rather than less. Whatever efficiency I was trying to gain gets drained through review.I wrote about this in my framework of the AI Flywheel, when I argued that multi-prompt chains compound the potential for a negative experience, because a single ineffective step poisons everything that follows. What I didn’t say then is what the compounding costs the person on the other end of it.
The design-to-code tools are trained on design systems and methodologies that are one-size-fits-all, and they have trouble interpreting a unique point of view. So for now, all of them have only earned the trust to receive one supervised task at a time, which is a long way from what they were sold to me as. My work with them stays highly iterative and demanding of my time. They are helpful in making me feel like work is progressing, but far from a full replacement of my attention, skill, and craft. I keep using them, but none of them has yet earned the right to deliver work I haven’t reviewed and edited.
I don’t think I’m unusual in my thinking or approach to using AI to aid my process. Thales’ Digital Trust Index this year found 93% of IT leaders already using, deploying or planning AI initiatives, while 77% of consumers are still concerned about AI agents acting on their behalf. Plenty of companies are shipping capabilities. User trust hasn’t kept up.
Trust is built by offering the user agency in early agentic setup and permissioning, allowing them to define the foundation of the trust contract. I wrote our AI trust principles. Of all the features and signals an agent can offer around transparency and auditability, the trust contract is the one I’d argue has to be in the first release.
What does a trust contract include? First, the user is invited to define what the agent can never do. From this, the agent can then infer what it is allowed to do, and determine when to ask the user for clarification or permission. This leaves the user in control of how much or how little they define, and how much agency and flexibility their agent is actually allowed. That also includes when and how actions get codified as general rules, or stay one-off decisions that never become rules at all.
Say what it cannot ever do, then let it determine where it has agency and flexibility.
This is the point where people who work in security get nervous, and they are right to. Defining what a system can never do is a weak way to secure it, because anything you forget to name is allowed by default. Layer in the non-determinism of LLMs, and an overly eager agent may ignore user-defined boundaries.
There must still be a layer of deterministic entitlements and access permissions, and they must not be conflated with the trust contract. The trust contract is applied on top of them. The contract doesn’t decide what data and tools the agent has at its disposal, it decides which of them it can act on autonomously, without asking permission. That layering is what lets the trust contract safely narrow the agent’s existing permissions. And if the agent finds it has access to a tool the contract never named, it should default to asking. The contract isn’t the safety mechanism. The permissions are. The contract only decides how often the agent has to interrupt me inside the space those permissions already made safe.
A P0 release must make room for those definitions alongside the typical product requirements. What a user would need to hand over for this to succeed, and what might make them distrust it, both belong in the first release, not in a later release after the user has stopped handing it anything, or trusting it with valuable work.
If you’re scoping a P0 right now, the trust contract belongs at the requirements stage, next to the capabilities. The definition of what the agent can do should also include the framework for how a person will tell it what it must never do. Those two elements must ship together.
The resistance to this gets stronger the higher in the organization it goes. Trust is not an easily tracked metric, certainly not through a direct quantitative one. At the executive level, many find it hard to understand how a specific resource investment in trust actually drives revenue, especially in the near term.
They’re not wrong to ask.
Despite strongly advocating for investment in user trust, I don’t have a direct measure for it. Instead I have proxies.
That last one is the closest I get to a direct reading, and also the softest, because agency granted is somewhat qualitative.
The issue is that those all lag. Every one of them moves after the investment, and usually after the quarter that funded it. So an executive who says they can’t see the return inside the window they’re accountable for is describing the situation accurately.
But one cost doesn’t lag. Success is time spent on the work rather than on the system. Review is what it looks like when that fails. The work comes back, somebody checks it, and the minutes you were trying to save get spent anyway.
This is where my argument runs out. I can name the cost. I haven’t measured it. Everything I’ve said about review burden comes from my own desk, not a dashboard, and until someone instruments it properly, an executive is right to treat it as a story and not a number.
You’re not deciding whether to pay for trust. You’re deciding when to pay. Do it up front, in the first release, or pay for it later, in release after release spent rebuilding trust with the users who stuck around. And if you wait too long, in the ones you burn trying to win back the users who already left.
