Speaking Engineering: Disambiguation Frameworks for Business Owners
Module 1 of 7 Beginner 20 min

When Everyone Means Something Different — Why Disambiguation Matters

What You'll Learn

  • What business-engineering misalignment looks like in practice and why it happens even on well-intentioned projects
  • At least two concrete costs that misalignment creates — in money, time, and quality
  • Why detailed documentation cannot solve the disambiguation problem on its own
  • How to spot situations in your own business where the same word is being used to mean different things by different groups

Why This Matters

Every project starts with the same honest intention: "We all understand what we're building." And yet, by the time the system goes live, something has gone wrong. The feature works exactly as the engineers understood it — but not as the business expected it. Nobody lied. Nobody was careless. Everyone simply assumed that when they said the word "approval," the other person heard the same thing.

If you have ever sat in a post-launch meeting explaining why the system does not behave the way the business needed it to, you already know what this course is about. The cost of that gap — measured in rework hours, delayed product launches, and eroded trust between business and engineering teams — is not a technical problem. It is a communication problem. And it has a name: misalignment. The good news is that structured techniques exist to surface and resolve it before it becomes expensive. The rest of this course introduces those techniques. But first, we need to understand the problem clearly enough to feel why it matters.

Core Concept

When people in different roles work on the same business process, they each develop a mental model of how that process works. This is natural and unavoidable — a Sales manager and an Underwriting analyst see the same insurance policy from entirely different angles. The trouble begins when those mental models stay separate and invisible, and the team assumes they share one.

There are three recurring patterns of misalignment to watch for.

Pattern 1: Same word, different meaning. This is the most dangerous pattern because it is hardest to detect. Everyone nods along in the meeting. Everyone uses the word "approval." But each person is imagining a different behavior. For an Underwriting analyst, "approval" means a risk decision has been made and a policy can be issued. For a Claims handler, "approval" means a settlement amount has been authorized. For a Sales agent, "approval" means a customer has confirmed they want to move forward. For an engineer reading a requirements document that says "the system shall support approval workflows," all of these meanings are simultaneously plausible. And when Engineering must make a decision under deadline, the interpretation they choose becomes the fourth meaning — embedded silently in the code.

Pattern 2: Different words, same thing. The inverse problem. The Sales team calls someone a "prospect." The engineering team calls the same person a "user." The Underwriting team calls them an "applicant." When the engineer builds a "user profile," the Sales manager does not recognize it as the thing they asked for — because they asked for a "prospect record." Nobody is describing a different concept; they are just using different labels. The confusion is purely terminological but the consequences are real: the wrong fields get captured, the wrong screens get designed, and two teams build two versions of the same concept.

Pattern 3: Silent gaps. Sometimes a term was never defined by anyone. It appeared in a requirements document — perhaps as "the system shall track customer status" — and everyone assumed that phrase was self-explanatory. In practice, "customer status" means something different in every corner of the business, and the engineer who had to make a decision under deadline simply picked one. The gap is silent because nobody noticed there was a question to answer.

What makes all three patterns expensive is timing. If the misalignment is discovered during a planning workshop, the cost is a one-hour conversation and a decision. If it is discovered during testing, the cost is a sprint of rework. If it is discovered after launch, the cost is months of remediation, a delayed product, and a credibility problem between the business and engineering teams.

The research is clear on the scale of this: misalignment between business and technology teams is a primary driver of the more than 30% of technology projects that run over budget and behind schedule. Some estimates put the cost of preventable rework at 30–50% of a project's total budget. These are not edge cases. They are the baseline for projects that do not actively address disambiguation.

Disambiguation — the practice of making implicit assumptions explicit and shared — does not eliminate misalignment overnight. But it reduces the window in which unresolved ambiguity can cause damage. And when disambiguation happens in a structured, collaborative way, it does something that no requirements document can do: it puts two people who use different words in the same room and forces them to discover the difference.

Concrete Example

Let's look at what this cost looks like in practice.

Meridian Insurance is a mid-sized insurer launching a new small business property insurance product. The project involves four groups: Sales, Underwriting, Claims, and Engineering. Each group has a stake in how the product works.

Early in the project, a requirements document is written. One line reads: "The system shall route applications through an approval workflow." Everyone on the project review signs off. The document is clear enough — or so everyone believes.

Engineering builds the approval workflow. They speak most frequently with the Underwriting team, who are the most technically engaged stakeholders. In Underwriting's world, "approval" means a risk analyst has scored the application, the risk is within acceptable bounds, and the policy can be issued. The workflow the engineers build reflects exactly that: a structured risk-scoring step that ends in a policy issuance event.

Three months later, the system is ready for testing. The Sales team sits down with it for the first time. They immediately raise a problem: "Where is the approval step where we confirm the customer wants to proceed?" They have been expecting a step where a Sales agent formally records the customer's verbal commitment — what they call "approval." That step does not exist in what was built.

Then Claims weighs in. "And what about our approval? When a loss is assessed and a settlement offer is made, Claims needs to record that the claimant approved the settlement." That step also does not exist.

The word "approval" carries four different meanings across the four groups: three explicit ones held by Sales, Underwriting, and Claims, and one implicit one that Engineering chose under deadline. The requirements document used the word once. Engineering built one workflow based on one interpretation. The cost of realigning the system: three months of rework and a delayed product launch.

This is not a story about engineering incompetence or business carelessness. Everyone did their job in good faith. The problem was structural: the disambiguation that should have happened at the start — "what do we each mean by approval, and which of those meanings does this system need to support?" — never happened.

The same story plays out in every industry. A hospital builds a scheduling system where "appointment" means something different to the clinical team and the billing team. A logistics company builds a document management system where "approved" means something different to operations and compliance. A bank builds a lending platform where "decision" means something different to credit analysts and relationship managers. The details change; the pattern is identical.

Analogy

Think of it like a recipe passed between cooks in different kitchens.

A recipe calls for "a medium onion, diced." In one kitchen, medium means about the size of a fist; in another, it means whatever was in the bag; in a third, it means precisely 150 grams. "Diced" means a quarter-inch cube to a classically trained chef and "chopped roughly" to someone cooking at home. If all three cooks are making the same dish for a dinner party, the dish will come out differently in every kitchen — not because anyone made a mistake, but because the recipe assumed a shared definition that did not exist.

Written requirements are like that recipe. They look complete. They look precise. But they carry embedded assumptions about what the words mean, and those assumptions are invisible until someone opens them in a different mental kitchen and makes a different dish.

The solution is not to write a longer recipe. The solution is to cook together at least once, so the definitions become explicit and shared through direct experience rather than interpretation.

Going Deeper

The misalignment problem has a well-documented history in software development. Eric Evans argued, in his 2003 book Domain-Driven Design, that without a precise, shared vocabulary used consistently by both business and engineering, every conversation required invisible translation — and that translation introduced errors. (You will encounter Evans's term for this shared vocabulary in the next module.)

Martin Fowler, writing on the same idea, put it this way: without a ubiquitous language, "developers and business people need to constantly mentally translate terms when communicating with each other." That translation is the source of misalignment.

What is less often discussed is how ambiguity compounds. A single ambiguous term in a requirements document does not produce one misunderstanding — it produces a branching tree of misunderstandings, each decision made under that ambiguous term becoming a buried assumption in the code. When the mismatch surfaces, unwinding it means tracing back through every layer of assumption. The later in the project timeline that happens, the more expensive it is.

There is also an important distinction between ambiguity that is visible and ambiguity that is invisible. When two people actively disagree — "I think approval means X, you think it means Y" — that disagreement is a productive signal. You can resolve it. The more dangerous case is when both parties believe they agree, and the difference only surfaces when the system behaves unexpectedly. Effective disambiguation does not just resolve known disagreements; it surfaces the unknown ones.

Finally, it is worth noting that business vocabulary is not static. As companies change their products, enter new markets, and reorganize teams, the meaning of terms evolves. "Customer" at a company that only sold direct means something different after they add a reseller channel. Disambiguation is not a one-time event at project kickoff — it is a practice that must be revisited whenever the business changes in ways that affect the domain.

Common Misconceptions

"Good documentation should prevent this."

This is the most common objection, and it deserves a direct answer. Written requirements do capture intent — but they cannot capture the reader's interpretation. When you write "the system shall support approval workflows," you are recording your mental model of what approval means. Every reader decodes that sentence through their own mental model. If their mental model differs from yours, they walk away from the document feeling aligned while holding a different understanding. The gap is invisible in the document. Documentation alone is not a disambiguation tool; it is a record-keeping tool. Disambiguation requires active dialogue — questions asked and answered between specific people who hold different mental models.

"Misalignment only happens on large, complex projects."

In practice, misalignment is not correlated with project size — it is correlated with the number of distinct roles involved and the degree to which those roles use specialist vocabulary. A small team of three people building a simple feature can still fail if the product owner's definition of "ready" differs from the engineer's, or if what the business means by "notification" does not match what gets built. Complexity amplifies the damage of misalignment, but it does not cause it.

"Once we've aligned on terminology, we're done."

Disambiguation is not a checkbox you tick at a kickoff workshop. Business vocabulary changes as the business changes. New market segments, new product lines, new regulatory requirements, and new team structures all shift what words mean in practice. Organizations that treat disambiguation as a one-time event find themselves replaying the same expensive discovery conversations every time the business evolves. The goal is not alignment achieved — it is alignment maintained through ongoing practice.

Check Your Understanding

  1. Think of a project you have been involved in that encountered unexpected rework or misaligned expectations after development was underway. Which of the three misalignment patterns — same word, different meaning; different words, same thing; or silent gap — most closely describes what happened?

    Reveal answer This is a reflective question with no single correct answer. The key is to locate a specific term or concept that was used during planning and trace how different stakeholders held different definitions of it. In most cases, the most common pattern will be "same word, different meaning" — because that is the pattern that produces the most confident false alignment. Silence in a meeting is not agreement; it often means everyone assumed they shared a definition they did not.

  2. Why does the timing of when misalignment is discovered matter so much? What changes between discovering it in a planning workshop versus discovering it after launch?

    Reveal answer The cost of resolving misalignment scales roughly with how embedded the incorrect assumption has become. In a planning workshop, a misaligned definition is just a conversation — cheap to correct. Once code has been written around the wrong definition, fixing the misalignment means changing the code. Once the system is live and other systems or workflows depend on it, changing the behavior breaks those dependencies too. The longer a wrong assumption is allowed to propagate, the more of the system it infects.

  3. A colleague argues: "We can solve this by writing more detailed requirements — if we are specific enough, there's no room for misinterpretation." How would you respond?

    Reveal answer More detailed requirements reduce some forms of ambiguity but do not eliminate the core problem. The issue is not the quantity of words in the document — it is that every reader decodes those words through their own mental model. A ten-page requirements document can be read by five people who each walk away with five slightly different understandings. The only way to surface those differences is through dialogue, not through more writing. Documentation records the outcome of disambiguation; it does not produce it.

  4. The Meridian Insurance scenario shows "approval" carrying four different meanings across the four groups involved. Why was this not caught when the requirements document was reviewed?

    Reveal answer Because the word "approval" appeared once in the document, and each of the four groups decoded it according to their own role — including Engineering, who defaulted to the definition they heard most often (Underwriting's). Everyone who reviewed the requirements felt satisfied that their understanding was captured. The word was familiar enough that no one felt the need to ask "what do you mean by that?" This is the core danger of using everyday business vocabulary in requirements: familiarity creates false confidence. The word feels defined when it is not.

  5. Disambiguation is described as an ongoing practice, not a one-time event. What kinds of business changes should trigger a team to revisit their shared terminology?

    Reveal answer Any change that shifts the meaning, scope, or ownership of a concept in the business. Examples include: entering a new market segment that adds a new type of customer; launching a new product line that changes what "policy" or "order" means; a regulatory change that redefines a compliance term; a reorganization that moves ownership of a process from one team to another. In practice, a good heuristic is to revisit terminology whenever the business has a conversation that begins "wait, what do we mean by X these days?"

Key Takeaways

  • Misalignment between business and engineering teams typically traces back to ambiguous terminology — the same word meaning different things to different roles, or silent assumptions that were never made explicit.
  • There are three recurring patterns to watch for: same word, different meaning; different words, same thing; and silent gaps where no one defined the term at all.
  • The cost of misalignment scales with time: a conversation in a planning workshop costs almost nothing; the same misalignment caught after a launch can cost months of rework.
  • Written requirements documents record intent but cannot resolve interpretation — active dialogue between people who hold different mental models is the only way to surface hidden differences.
  • Disambiguation is not a one-time event: as your business evolves, its vocabulary evolves with it, and the practice of making meaning explicit must evolve too.

References