User acceptance: it works — but does it do the job?

The short version. Technical testing asks "does it do what we built it to do?" Acceptance asks a harder question: "does it do the job the user hired it for, in their world, without you standing next to it?" Plenty of products pass the first and quietly fail the second — and users rarely tell you. They just stop coming back.

1. Define "accepted" with the user, in their words

Before any pilot, agree what success looks like — with the user, not about them. Not "no critical bugs" but "I processed Friday's orders in this instead of the spreadsheet, and it took less time." Written down, specific, theirs. If you can't get a user to state what would make them keep it, that is acceptance failing early — which is the cheap place for it to fail.

2. Watch real tasks in the real environment

A demo you drive tells you nothing; the phone rings, the wifi drops, the data is messier than your test data, and the user has nine other things open. Sit beside (or screen-share with) a handful of real users doing their own work with it, and say as little as possible. The moments that matter are the hesitations, the wrong turns, and the point where they reach for the old spreadsheet — each one is the product telling you where it doesn't fit their world yet.

3. Structure a pilot like an experiment, not a favour

The shapeless pilot — "have a play and tell us what you think" — produces polite noise. Give it edges: a few real users, their real work, a fixed period, the acceptance criteria from step 1, and a scheduled end conversation. And agree the exchange up front: they get early access and influence; you get honesty and a decision at the end — keep it, fix it, or drop it.

4. The silence trap

Users do not report problems; they route around them, exactly as they routed around the problem your idea addresses. Silence during a pilot is not approval — it is often abandonment you haven't noticed yet. Watch what they do: log-ins, completions, the tasks still being done the old way. A user who complains is engaged; the one who says nothing has usually already left.

5. Keep a friction log, and let it set the roadmap

Every hesitation, workaround and "oh, I didn't realise" goes in one list, dated and verbatim. At the end of the pilot this log — not your feature wish-list — is the roadmap. Fixing the top three frictions almost always beats adding the next feature, because the frictions are standing between existing users and the job, while the feature is a guess about hypothetical ones.

6. When acceptance fails, the spec was wrong — not the user

The reflex is to explain, train, or document harder. Occasionally that is right; usually it is the product insisting the world adapt to it. If several sensible people misuse it the same way, that is the design. The pilot did its job: it found the gap between what you built and the job to be done, while the gap was still cheap to close.

The whole thing, on one line

Agree "accepted" in the user's words → watch real tasks in the real environment → give the pilot edges and an end date → treat silence as a warning, not a pass → and let the friction log, not your wish-list, write the roadmap.