Everyone Agreed in the Meeting. Nobody Meant the Same Thing.

Picture the kick-off meeting for an internal approvals system. The client says the new system must be fast. The developer writes down a response time of 300 milliseconds. The business owner, who has watched staff click through six screens to submit one request, hears fewer clicks. The clerk who will use it every day hears something else: no more waiting two days for a manager to approve a form. Everyone nods, and the minutes record one line: the system must be fast.

Months later, at acceptance, the developer demonstrates pages that load in a fraction of a second. The owner counts the same six screens. The clerk still waits two days, because the approval workflow was never in scope. Each of them was right about what "fast" meant, and the system still fails acceptance. The argument that follows is about who misunderstood whom, and it is the most expensive kind of argument, because it happens after the money is spent.

A nod is not a definition

Meetings reward agreement. Nodding costs nothing, and asking "what do you mean by fast?" can sound as if you were not listening. So the word passes through the room, and each person files it under their own problem. Nobody lied. They agreed on a word and left with three meanings.

Some words do this more than others, and they are usually the ones nobody thinks to question: fast, simple, secure, real-time, report, and even user. Each sounds precise. Each means something different to the developer, the person paying and the person doing the work.

The cost of the gap does not appear in the meeting. It appears at acceptance, when the software exists, the budget is committed and every correction is a change request. I have worked on government-scale systems from pre-sale to handoff, and the cheapest moment to fix a vague word is the first time somebody says it. After that, every week adds design, code and expectation on top of whichever meaning each person chose.

Ask what happened, not what they would like

The usual question makes things worse. "Should the system be fast?" has one possible answer, and that answer tells you nothing. Rob Fitzpatrick's book The Mom Test deals with the same problem in customer conversations: people are polite, and opinions cost them nothing. In his own slides on the method, one of the rules for good questions is to ask about specifics in the past. He treats generic claims, promises about the future and hypotheticals as fluff, and asks instead for the last time something actually happened.

The book was written for founders testing business ideas, but the rule works just as well in a requirements meeting. Instead of asking what "fast" should mean, ask about the last time the current process felt slow:

• "Walk me through the last request that took too long. What happened, step by step?"
• "Where were you waiting, and for whom?"
• "What did you do while you waited?"
• "How did you know it was finished?"

Ask the same questions of the developer, the owner and the clerk, and you will usually hear three different stories behind one word. That is the result you want. You have not created a disagreement. You have found the one that was already in the room.

Turn each word into something you can watch happen

Once you know which "fast" you are dealing with, write it down as behaviour someone could observe, with an example or a number attached. Dan North's article "Introducing BDD" (2006) describes acceptance criteria as scenarios, in a form that is hard to improve on: "Given some initial context (the givens), When an event occurs, Then ensure some outcomes."

For the clerk's meaning of fast, that becomes: given a purchase request below the manager's approval limit, when the clerk submits it, then the manager is notified within five minutes and the request is approved or rejected within one working day. That sentence can be tested, demonstrated and signed. "Fast" cannot.

There is a technical payoff as well. A criterion in this form can become an automated test, so the definition stops living in meeting notes and starts failing the build when someone breaks it. For performance words, also say where the number is measured, on the server or in the user's browser, and at which percentile. Otherwise two honest people will measure two different numbers, and both will be right.

Source: invented for this example.

Read it back in their words

The last step is the one most often skipped. Before the meeting ends, read each definition back in the client's vocabulary, not yours: "So by fast, you mean a request under the limit gets a decision within one working day, and the screens can stay as they are?" If they correct you, the readback has just paid for itself. If they agree, you now have agreement on a sentence instead of a word.

Then keep the definitions where people will meet them again: in the backlog, next to the work, as a short glossary of the project's loaded words. A glossary entry is cheap to change in the first week. The same change during user acceptance testing is a dispute.

This is the execution side of Beyond the Obvious, where I wrote about the gap between the problem a person states and the need behind it. Asking for the last real example is how you find the need; writing it as an acceptance criterion is how you keep it. And as Show Me the Money! argued, the customer pays for the job the software does, not for the adjective in the minutes.

So treat a meeting where everyone agreed at once with some suspicion. If nobody in the room disagreed, you probably have not asked a specific enough question yet.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.