Why AI Engineers Must Talk to Customers

The best AI engineers I know do something most engineers avoid: they talk to customers. Not just to demo. To listen.

I've run discovery sessions with cruise line operators, people who manage vessel IT, port logistics, and crew workflows. They don't speak in tokens or vector embeddings. They speak in problems. And those problems are almost never the ones you assumed before the call.

What customers actually say

Here are real categories of feedback I've heard, paraphrased, from customers at Xcontrol:

• "We lose connectivity mid-voyage and the system just… stops. No error, no fallback."
• "My team can't troubleshoot this without calling Hamburg. That can't be the process."
• "The crew doesn't use it because it takes too long. They just go back to the spreadsheet."
• "I don't need it to be smarter. I need it to be faster and more reliable."
• "Who do I call if this breaks at 2am on the Atlantic?"

None of those are things you would have built against if you'd only read a requirements document.

The gap between spec and reality

In most engineering orgs, requirements come in through a chain: customer → sales → product → spec → engineering. By the time you see a ticket, the original problem has been translated three times. Sometimes the translation is faithful. Often it isn't.

When engineers talk directly to customers, two things happen:

• You hear the real problem. Not the feature request, the underlying job-to-be-done. "We need a search box" often means "we spend 20 minutes every morning finding a specific type of document."
• You can push back intelligently. When you understand the context, you can say "actually, what if we just surfaced that document automatically based on the shift schedule?" instead of building yet another search box.

A simple framework for discovery sessions

Before the call

• Write down what you think the problem is. You'll be wrong. That's the point.
• Prepare 3–5 open questions, not yes/no questions.
• Block time after for notes, don't rely on memory.

During the call

• Ask "walk me through a typical day" before asking about the product.
• When they describe a problem, ask "how often does that happen?" and "what do you do currently?"
• Never pitch during discovery. Listen first.
• Ask "what would perfect look like?", you'll learn more from their answer than from any spec.

After the call

• Write up key themes within 30 minutes.
• Share back a summary with the customer, it builds trust and catches misunderstandings.
• Turn insights into user stories with clear acceptance criteria before they reach a sprint.

Engineering without customer context is just expensive guessing.

Why this matters more for AI

For conventional software, a wrong assumption usually means building the wrong feature. For AI, it can mean building an entire pipeline around the wrong signal, choosing the wrong retrieval strategy, optimising for the wrong latency target, or using an LLM where a simple rule would do.

AI systems also introduce new failure modes that customers don't have vocabulary for: hallucinations, context window limits, embedding drift. Part of the discovery process is teaching customers what questions to ask, and learning from their operational reality in return.

The engineers who build the best AI products are the ones who are genuinely curious about what their users are trying to do. Get in the room. Ask dumb questions. The requirements you think you have are rarely the ones you need.