Working directly with clients
Consultancy and agency work asks for something product-team experience does not teach: the person you are negotiating scope with is paying, the relationship is commercial, and “we’ll figure it out next sprint” costs somebody money.
Working With Ambiguity / Unclear Requirements covers ambiguity when the requirement is internal. This is the external version, where the same ambiguity has a price attached.
What changes when the stakeholder is a client
| Internal | Client |
|---|---|
| Scope drifts, budget absorbs it | scope is the contract |
| Trust assumed | trust is earned per delivery |
| Shared context | you learn their domain |
| Disagreement is normal | disagreement is delicate |
The consequence: you cannot defer decisions the way you can internally. An unresolved question that a product team parks for a sprint becomes, in client work, either an assumption you wrote down or an argument in six weeks. Write it down.
Discovery: the questions that change the estimate
Most of what a client tells you first is the solution they imagined, not the problem. “We want an AI agent that handles support tickets” is a proposed implementation. Work back to the problem before quoting anything.
- What happens today, step by step, and who does it? Their process, not their aspiration. See Process mapping and choosing what to automate.
- What does success look like in a number? If nobody can name one, the project has no definition of done and will not end.
- What is the cost of being wrong? A wrong draft reply is a nuisance; a wrong refund is money. This decides how much human-in-the-loop you build, and it is the question that most changes the estimate.
- Which systems, and do they have APIs? A dependency with no API turns weeks into months.
- Who signs off, and who else has an opinion? The invisible stakeholder who appears at the demo is the classic schedule killer.
Ask the cost-of-being-wrong question early and out loud. It reframes the conversation from “can you build it” to “how right does it need to be”, which is the conversation you actually need to have.
Managing expectations about AI specifically
This is the part that distinguishes an AI consultant from a generic one, and it is worth being able to say cleanly.
The demo-to-production gap is wider for LLM systems than for anything else. A prototype that works on ten examples is genuinely easy and genuinely misleading — clients have seen the demo and reasonably conclude the work is nearly done. Naming the gap early, before it becomes a disappointment, is what buys you the budget for evaluation and guardrails.
Three things to establish in the first conversation:
- It will not be 100%, and the target is a negotiation. Get a number, and a plan for the remainder — a review queue, an escalation path. A system that handles 80% with a clean exception path ships; one aiming at 100% does not. See Design an internal automation platform.
- The same input can produce different output. Clients test by re-running the thing they just ran. Explain non-determinism before they discover it and conclude the system is broken, and show them what you assert on instead — Determinism and reproducible LLM tests.
- Quality costs money per request, forever. Unlike ordinary software, the better answer has a recurring unit cost. Surface the cost-quality trade as a decision they own rather than absorbing it silently.
Ship an evaluation set as a deliverable, not as internal tooling. It turns “is it good enough?” from an argument into a number both sides can look at, and it is the single most effective device for keeping an AI engagement calm.
Saying no, and the smaller thing
Refusing scope is a skill, and the version that works is never a bare no. It is no, and here is what I would do instead — a smaller thing that tests the risky assumption first.
The structure that lands:
- Restate what they want, accurately enough that they agree you understood.
- Name the specific risk — cost, timeline, a dependency, an accuracy ceiling.
- Propose the cheaper thing that resolves the uncertainty.
- Say what you would need to see to change your mind.
That last step is what separates it from obstruction. A client who hears “and if the pilot hits 85%, we build the full thing” is being offered a path, not a refusal.
Delivering, and being seen to deliver
- Demo working software early and often. In client work, visible progress is trust. Two weeks of silence reads as trouble regardless of the truth.
- Write decisions down where they can see them. A short decision log — what was chosen, what was rejected, why — prevents the six-week-later disagreement and doubles as your handover.
- Flag slippage the day you know, not at the deadline. Clients forgive delays and remember surprises.
- Hand over something operable: runbook, dashboards, what to do when it breaks, what it costs to run. See Incident response, runbooks and postmortems.
Working across languages and timezones
International client work adds a constraint worth naming: much of the communication is written, asynchronous, and in a second language for at least one side.
Write for that. Short sentences, one decision per message, the question at the top rather than after three paragraphs of context, and an explicit deadline for the answer. Confirm understanding by restating rather than by asking “does that make sense?”, which reliably gets a yes. When a decision matters, put it in writing after the call — a two-line summary of what was agreed catches misunderstandings while they are still cheap.
Related
Interview angle 4
- “How do you handle a client who asks for something you think is wrong?” - never a bare no. Restate their goal so they know you understood, name the specific risk, propose a smaller thing that tests the risky assumption, and say what evidence would change your mind. The last part is what makes it a path rather than a refusal.
- “A client saw the demo and thinks it’s nearly done.” - the demo-to- production gap is wider for LLM systems than anything else, and naming it early is what funds evaluation and guardrails. Establish three things up front: it will not be 100% and the target is negotiable, output is non-deterministic, and quality has a recurring per-request cost.
- “How do you scope an AI project?” - work back from the proposed solution to the problem, then ask what the cost of being wrong is. That single question decides how much human-in-the-loop you build and moves the estimate more than anything else.
- “How do you keep a client confident mid-project?” - visible progress. Demo early and often, keep a decision log they can read, and flag slippage the day you know rather than at the deadline. Delays are forgiven; surprises are not.