When they read the architecture section of your proposal, does it sound like this?
We leverage event-driven microservices to decouple ingestion from downstream consumers, enabling horizontal scaling and eventual consistency across the data plane.
It reads well. It sounds like a senior architect wrote it. Every technical term is correct.
Now picture the buyer reading it. Their CFO has a question about data loss. Their operations lead wants to know what happens during an outage. Their IT director wants to know where the data lives.
The sentence answers none of those questions. It answers a question nobody asked: whether you know the vocabulary.
Read the sentence again, one phrase at a time, and ask what the buyer gets from each.
"Leverage." Nothing. It's a verb that means "use" wearing a suit.
"Event-driven microservices." A category, not a fact. It tells the buyer your architecture has a name. It doesn't tell them what happens when a record arrives.
"Decouple ingestion from downstream consumers." This is the closest thing to a useful claim, and it's still a claim the buyer can't check. What does decoupled mean for their data?
"Enabling horizontal scaling and eventual consistency across the data plane." Three more terms, none of them defined, and "eventual consistency" will make a careful reader pause. Does that mean their numbers might disagree for a while? Does that matter for their reporting?
The sentence doesn't hide the answer. It just makes the answer cost the reader effort to find, and most readers won't spend it.
That's the jargon tax. You pay it in every sentence, and the buyer pays it in time, and some of them stop paying.
After:
When a sales record is created in your system, it's written to a queue first, then copied to your reporting database within about thirty seconds. If your reporting database is down, records wait in the queue and nothing is lost. When it comes back, they're copied in the order they arrived.
Same system. Same architecture. Different sentence.
The reader can now check it. They can ask a specific question: what happens if the queue fails? The answer is already in the paragraph, so the conversation moves to their actual concern.
The Three Moves
The rewrite did three things, and you can run the same three moves on any sentence.
- Name the thing the buyer can see. “A sales record is created.” Not “data ingestion.” The reader can picture the record.
- State the consequence they care about. “Nothing is lost.” Not “eventual consistency.” The consequence is what they’re buying.
- Give a number or a condition. “Within about thirty seconds.” Not “near real-time.” A number is a claim the reader can test, and a claim they can test is a claim they’ll trust.
The technical term is still there if they want it. You can add it in parentheses after the plain version. But the plain version comes first, because the buyer reads the first version and skims the rest.
The Counterintuitive Inversion
The more precise the vocabulary, the less precise the claim.
"Event-driven microservices" sounds exact. It's a category with dozens of implementations, and the buyer doesn't know which one you built. "Written to a queue, copied within thirty seconds" sounds plainer. It's far more exact, because it describes the behavior the buyer will live with.
Experts reach for jargon because it signals they know the field. Buyers read jargon as a sign that the vendor is describing the vendor's world, not theirs.
The sentence that sounds least impressive is often the one that earns the most trust.
Three Bold Contexts
Context 1: The Glossary SE Writes every proposal section in the vocabulary of the product team. Customer reads it twice, can't find the answer, and sends a list of clarifying questions that the SE answers on the next call. Customer thinks, "They're hard to work with."
Context 2: The Translator SE Writes the same section, then rewrites each claim as a behavior, a consequence, and a number. Keeps the technical term in parentheses. Customer reads it once and asks about the one thing they actually need to know. Customer thinks, "They understand what we're trying to do."
Context 3: The Dumbed-Down SE Strips out all the technical language to avoid sounding like a jargon machine. Customer's engineering team reads the section and asks where the architecture details went. Customer thinks, "They're hiding the real design."
The goal is Context 2. Plain first. Precise second. Technical terms as a reference, not a wall.
Pattern to Remember
The Jargon Tax: Every technical term you use without defining it costs the reader time, and some readers won't pay. The sentence that sounds most expert is often the one the buyer can verify least. Vocabulary signals expertise to other experts. Behavior, consequence, and number signal it to the people deciding whether to buy.
The fix: Read each sentence in your proposal and name the thing the buyer can see, the consequence they care about, and the number or condition that makes it testable. Put the term in parentheses after the plain version, not in front of it.
Hit reply and tell me: What's a term you use in every proposal that your buyers have never once explained back to you?
(Anonymized, always.)
