TLDR: Customers will never speak our language. They shouldn’t have to. The burden of translation is on us.

The communication gap between developers and customers is real, and it rarely closes from their side. Customers bring problems; we bring solutions. Yet somewhere in the middle, a lot gets lost in translation. Both sides are aiming at the same target (software that actually solves something), and both sides can still miss it.

This post looks at why the gap exists, why the burden of closing it lands on developers, and what tools actually help.

Prefer video? I gave a version of this talk at Italian Agile Days 2024. This post is the written, expanded take.

Customers Don’t Know the Jargon

Consider this scenario: a customer approaches a development team asking for website enhancements. Their language lacks the technical vocabulary familiar to developers. Their focus is on outcomes, not implementation.

Here’s one way the conversation can go.

Going Badly:

Customer (Business Owner): “We need the website to be more engaging. Can we add something dynamic to the homepage?”

Developer: “Sure, we can build that with React or Vue. Want sliders, scroll-triggered animations, interactive forms, or a hero carousel?”

Customer: “Um. I don’t know what any of that means. I just want the homepage to feel more alive.”

Developer: “Right, so we’d use Framer Motion for the animations and maybe GSAP for the scroll effects.”

Customer: “…Sure. Whatever you think is best.”

The customer just abdicated the decision. The developer walked away feeling efficient. Six weeks later, the homepage has a beautiful scroll-jacking animation, bounce rate went up, and nobody knows why.

Here’s the same opening, handled differently.

Going Well:

Customer (Business Owner): “We need the website to be more engaging. Can we add something dynamic to the homepage?”

Developer: “What does ’engaging’ look like to you - people staying longer, clicking more, coming back?”

Customer: “Mostly staying longer. Right now people bounce in five seconds.”

Developer: “Got it. Do you have a sense of what they’re missing? Is it that they can’t tell what we do, or that the page feels boring?”

Customer: “They can’t tell what we do. Our last three customer interviews all said ‘I wasn’t sure if this was for me.’”

Developer: “Then we probably don’t need more motion, we need clearer positioning. Let me sketch a couple of options.”

Same starting sentence. Completely different project. In the first dialog, the developer optimized for the customer’s request. In the second, they translated the request into the actual problem, and found out it wasn’t quite the one being asked for.

While most people understand technology to some extent today, we can’t expect everyone to be proficient. That’s why we have different professions. Consider the reverse: when we go to a doctor, do we understand everything they say? If not, whose job is it to close that gap - the patient’s, or the doctor’s?

They Bring a Problem to Us to Solve

Customers approach developers with problems, not specs. They already have enough to manage running their business. For them, it’s about achieving an outcome, not understanding the plumbing.

Going Badly:

Customer (Project Manager): “We’re expecting a huge surge in traffic for Black Friday. Can we handle it?”

Developer: “Depends. What’s our current p99 latency under load? And do we have autoscaling on the API tier, or just the edge?”

Customer: “I… don’t know. Is that something we should have?”

Developer: “Well, without it we’d need to pre-warm instances. Also, our DB connection pool is probably the bottleneck. We’d want to look at PgBouncer or RDS Proxy.”

Customer: “OK, so… can we handle it or not?”

Developer: “It depends on our cache-hit ratio.”

The PM walks away with less confidence than when they arrived. They asked a business question and got a technical interview. Nobody’s closer to knowing whether the site will stay up on Friday.

Going Well:

Customer (Project Manager): “We’re expecting a huge surge in traffic for Black Friday. Can we handle it?”

Developer: “Short answer: probably, but let me make sure. How big of a surge, compared to a normal day?”

Customer: “Marketing predicts 200% over last year.”

Developer: “OK. That’s higher than anything we’ve tested, so I’d like to run a load test this week. If it holds, we’re fine. If it doesn’t, I’ll know exactly what to fix and roughly how long it takes. Either way, I’ll have a clear answer by Thursday.”

Customer: “Perfect. And let’s freeze feature work until after the weekend.”

Same opening question, two very different meetings. In the first, the developer asked the customer to do their job. In the second, the developer did it themselves - and left the customer with a plan, a timeline, and a date. The technical detail is still in there, it just didn’t travel home with the customer. Translate on our side of the desk, not theirs.

It’s Not Their Job

A car mechanic doesn’t expect customers to understand wheel alignment geometry. Customers don’t need to grasp the technical nuances of software development. They rely on us to translate their requirements into working solutions.

One of my university professors worked on the development of the first defibrillator. The electrical engineering team sat down with the doctors to understand the requirements. The conversation went something like this:

Doctor: “Our task is simple. When a patient’s heart is beating chaotically, we need to drive a current through it to restore the rhythm.”

Engineer: “Understood. How much current are we talking about?”

Doctor: “Big.”

Engineer: “But if we drive a big current through a human body, it will burn.”

Doctor: “Not that big.”

Both sides were experts. Neither side could do the other’s work. The only way forward was for the engineers to learn enough about medicine, patient safety, and clinical outcomes to turn “big, but not that big” into a number with units. The burden of translation landed on the builders. It always does.

Multiple Customer Personas

“The customer” is rarely one person. A typical project involves end users, product managers, business owners, analysts, and sometimes compliance or legal. Each brings a different vocabulary, and none of them is ours.

• End users describe experience: “it’s slow,” “I can’t find the button”
• Product managers describe outcomes: “we need to improve activation”
• Business owners describe money: “we’re losing deals because of X”
• Compliance describes rules: “we can’t store that data for more than 30 days”

All four can be describing the same feature. Our job is to hold every translation at once and write code that honors every one of them. That’s harder than any single translation, and it’s the reason we can’t expect customers to meet us halfway - we’re already translating between several of them.

The Importance of Speaking the Same Language

Despite the challenges, developers and customers have to speak the same language to collaborate successfully. This is the core idea behind Domain-Driven Design (DDD) and its ubiquitous language: a shared vocabulary used by everyone on the project, from the business conversation to the code.

To see why it matters when the language breaks, consider the Mars Climate Orbiter:

Mars Climate Orbiter went out of radio contact when the spacecraft passed behind Mars… 49 seconds earlier than expected, and communication was never reestablished. Due to complications arising from human error, the spacecraft encountered Mars at a lower-than-anticipated altitude and it was either destroyed in the atmosphere or re-entered heliocentric space after leaving Mars’ atmosphere.

The root cause was a unit mismatch between Lockheed Martin’s ground software and NASA’s navigation system. Lockheed’s code output thruster impulse in US customary units (pound-force-seconds), while NASA’s code expected SI units (newton-seconds). The tiny error compounded across months of trajectory corrections until the orbiter approached Mars at an altitude no one intended.

The “beauty” of this situation is that both teams consisted of engineers. Yet they didn’t share a language. The gap gets wider when a technical team and a non-technical stakeholder have to align. In aviation, automotive, or medical software, the gap can cost lives.

So we have to speak the same language. And we’ve already established that customers won’t speak ours. That leaves us with one option.

Developers Need to Learn the Customer’s Language

To close the gap, we have to engage with customers on their terms and adopt their vocabulary. Once we understand their domain, priorities, and constraints, we can build solutions that actually fit.

A few techniques that work in practice:

• Build a shared glossary. Write down every domain term the business uses, with its definition in their own words. When a term is ambiguous, push back until it isn’t. The glossary becomes the source of truth for class names, table names, and API fields - everything the code touches.
• Don’t invent new words. If the client talks about “buyers” in a webshop, don’t call them “users” in the code. Translating business terms into generic technical ones is how domain knowledge leaks out of the codebase.
• Use Example Mapping. Ask for concrete examples of the rule the customer just described, including edge cases. “Show me an order where this applies. Now show me one where it doesn’t.” Examples expose assumptions that abstract rules hide.
• Run Event Storming workshops. Walk through the domain on a wall of sticky notes with customers, developers, and domain experts in the same room. It looks chaotic at first; by the end, the domain has a shared shape. Every session I’ve run has surfaced something even the domain experts didn’t know about their own business.

Conclusion

Customers won’t speak our language. They shouldn’t have to. Translating their domain into working software is what we’re paid for. The doctors didn’t owe the engineers a specification in amps. Our customers don’t owe us one in classes and APIs.

The good news: the tools exist. A shared glossary, stubborn clarifying questions, Example Mapping, and Event Storming. None of it is exotic. All of it is work we can start on Monday morning, without asking for permission.

TLDR: Stop waiting for the customer to learn your language. Learn theirs. Start with a shared glossary this week - every term you write down today is an argument you won’t have six months from now.

Cover image generated with Google Gemini.