Skip to content
All articles
AI3 min read

Trust Is the Feature: Building AI Products People Believe

The hardest problem in AI products isn't capability — it's earning enough trust that people act on the output. Here's how I design for it.

Most AI demos are impressive. Most AI products are abandoned. The gap between the two is rarely capability — it's trust. A model that's right 95% of the time sounds great until you realize users can't tell which 5% to ignore.

I've built two AI products to real usage, and the same lesson kept surfacing: trust is the feature. Everything else is table stakes.

Why accuracy alone fails#

A confidently wrong answer is worse than no answer. When an analytics copilot returns a revenue number that's subtly off, the user doesn't just distrust that number — they distrust the entire tool, and they tell their team.

The math is brutal:

  • A tool that's 99% accurate but opaque gets abandoned after the first visible miss.
  • A tool that's 90% accurate but transparent gets adopted, because users can verify and correct it.

Transparency compounds. Opacity decays.

Ground the model, don't just prompt it#

The single biggest lever for reliability is constraining what the model can say. Instead of open-ended text-to-SQL, I route generation through a governed semantic layer, so the model plans against blessed metrics rather than raw tables.

type SemanticQuery = {
  metric: "revenue" | "active_users" | "churn_rate";
  dimensions: string[];
  filters: Filter[];
  grain: "day" | "week" | "month";
};
 
// The model produces this structure — not raw SQL.
// A deterministic compiler turns it into a safe, correct query.
function compile(query: SemanticQuery): SQL {
  return planner.build(query);
}

By turning an open-ended problem into a bounded one, accuracy jumps and, more importantly, failures become legible.

Make the model say "I'm not sure"#

Coverage is seductive. Resist it. I add a verification pass that re-checks generated output against the schema and refuses anything referencing unknown fields.

Trading a handful of "I can't answer that" responses for zero confidently-wrong ones is almost always the right deal.

Show the work#

Every answer ships with the query it ran and the rows it touched. This does two things:

  1. It lets skeptical users verify results themselves.
  2. It turns power users into collaborators who fix your edge cases for you.

Perceived performance is a design problem#

Users tolerate latency if they see progress. Streaming the pipeline in stages — plan, then query, then chart — cut perceived wait time roughly in half without changing total compute.

The takeaway: in AI products, your job isn't to build the smartest system. It's to build the most trustworthy one. Capability gets the demo. Trust gets the retention.

  • AI
  • Product
  • LLMs
  • Engineering
Share