AI Features That Survive Real Users

17 June 2026 · 3 min read

blog contents
  1. Narrow beats clever
  2. Ground it in your own material
  3. Show the working
  4. Put a person where reversal is expensive
  5. Build the test set before you build the feature
  6. Watch what people ask, not what you expected

read

A demo answers the question you asked it. Production answers everything else, including questions the model has no basis for. The features that survive share a shape: a narrow job, answers grounded in your own material, a visible way to check the source, and a person in the path wherever being wrong is expensive. The model is the easy part.

Narrow beats clever

An assistant that will attempt anything fails in ways nobody can predict or reproduce. An assistant that does one job refuses the rest, and refusal is a feature.

Narrow scope also makes quality measurable. You cannot test everything, but you can test one job thoroughly.

Ground it in your own material

Most useful features are not asking a model what it knows, they are asking it to read your documents and answer from those. That changes the failure mode from invention to retrieval.

It also changes where the effort goes. Finding the right passage is harder than writing the answer, and it is where these projects actually succeed or fail.

Show the working

An answer with a link to the source it came from is checkable. Without it, users either trust everything or nothing, and both are bad outcomes.

Citations do more than build confidence. They give you a cheap way to spot a wrong answer, because the wrong source is visible immediately.

  • Which document the answer came from
  • A way to open that document at the right place
  • An explicit answer when nothing was found
  • A route to a human that does not restart the conversation

Put a person where reversal is expensive

Drafting a reply is safe. Sending it is not. Suggesting a refund is safe. Issuing it is not. The pattern is the same everywhere: let the model prepare, let a person release.

Confident wrong answers are a property of the technology rather than a defect awaiting a fix. Design the workflow to survive them instead of waiting for them to stop.

Build the test set before you build the feature

Collect real questions with answers you know to be correct, written down before launch. Fifty is enough to be useful and small enough to actually assemble.

Without that set, every change is judged on whichever answer someone tried last, and quality becomes a matter of mood. With it, you can tell whether a change helped.

Watch what people ask, not what you expected

The questions users bring are never the ones planned for. That gap is the most valuable output of the first month, and it is only available if the questions are recorded.

Read them weekly at first. They will tell you what to add to the source material, which is almost always a faster fix than touching the model.

questions

How do we know the feature is good enough?

Collect a set of real questions with known correct answers before launch, and rerun it after every change. Without that set, quality is an opinion that shifts with whoever used it last.

What should happen when it does not know?

It should say so and hand over. A clear miss costs far less than a confident invention, and users forgive the first far more readily than the second.

Do we need to train our own model?

Almost never at the start. Most requests that sound like training are really retrieval problems, and retrieval is faster to build, cheaper to run and much easier to correct.

More on this track

  1. How to Automate Your Business Automate in this order: count where the hours actually go, fix the process before encoding it, integrate the systems that make people retype data, add AI only where the input is messy and the output gets checked, and stop when the next item costs more to automate than it saves. 29 August 2026 · 3 min read
  2. Processes You Should Never Automate Automation multiplies whatever it touches. Point it at a good process and you get leverage, point it at a broken one and you get the same breakage at speed and at scale. Four kinds of work should stay manual: anything nobody has written down, anything that is decided rather than executed, anything rare enough that the rule never stabilises, and anything where being wrong is expensive to reverse. 5 August 2026 · 3 min read
  3. Find the Hours Worth Automating Most automation projects start with a tool somebody liked and work backwards to a problem. Start from the hours instead: for two weeks, record what the team actually repeats, how often, and how long it takes. The list that comes back is always shorter than the list people describe from memory, and the top item is almost never the one that gets complained about most. 21 July 2026 · 2 min read