Concrete beats abstract: the fastest fix for vague writing

The fastest fix for vague writing is swapping each abstraction for one concrete instance. A date instead of "soon". A number instead of "significant". The actual case instead of "some users". One example does more work than three adjectives.

This is a mechanical edit, not a talent. You can run it on a finished draft in two minutes, and it changes what happens after you hit send more than any other two minutes you could spend on the text.

Abstraction feels safe because it cannot be wrong

Writers go abstract to avoid being pinned down. "We're improving performance" cannot be contradicted by anyone. "The page loads in about a second now, down from four" can, and that risk is exactly what makes it worth writing.

Vague writing is rarely lazy. It is defensive. The abstract sentence is a hedge against being wrong, and readers can smell the hedge even when they cannot name it. This is why one update reads as confident while another, built on the same underlying facts, reads as evasive.

Concrete claims invite the pushback you need

A concrete word is a checkable word, and checkable is the point. "Thursday" invites a correction that "soon" never surfaces: someone replies that Thursday will not work because the review lands Friday, and now you know about a real constraint while it is still cheap to know.

"Soon" produces silent agreement between two people who mean different weeks. The disagreement still exists. It just gets discovered later, downstream, at whatever price downstream charges.

The one-example rule

Every general claim in a message should be able to produce one concrete example on demand, and a claim that cannot is not a claim yet. It is a hunch wearing a suit.

"Onboarding is confusing" should cash out to which screen, and confusing how. If you can name it, put the name in the message; the general claim plus its example is twice as persuasive at barely any extra length. If you cannot name it, that is worth discovering before you publish the opinion, and the failed search usually teaches you what you actually think.

Where abstraction hides at work

The same hiding spots show up in nearly everyone's writing.

• Status updates say "making good progress" instead of what got finished and what is left.
• Feedback says "tighten this up" instead of which paragraph and what is wrong with it.
• Asks say "more visibility" instead of the artifact you want and how often you want it.
• Promises say "we'll look into it" instead of who will, by when, and what counts as looked.

Each of these buys the writer comfort now and costs a follow-up question later. The follow-up always comes. Abstraction does not remove the reader's need to know; it reschedules that need into a second message.

A mechanical pass for concreteness

Concreteness can be edited in after the fact, one noun at a time.

• Mark every noun you cannot picture and every quantity you could not check.
• Replace each one with the instance you were actually thinking of when you wrote it.
• If there was no instance behind the word, delete the sentence. It was padding.

The pass is humbling the first few times. Sentences you liked turn out to contain nothing. Let them go. What remains is shorter, and much harder to argue with.

Here is the pass run on a real shape of update. Before: "Made solid progress on the migration this week, a few things still to iron out, but overall trending well." After: "Migration: the user table is moved and verified. Billing is half done; the blocker is a schema question for Dana. I expect to finish Wednesday." The first version asks the reader to trust a feeling. The second hands them three facts and a date, and it happens to be shorter.

A concrete promise is a reputation instrument

Concrete promises compound in a way abstract ones cannot, because only concrete promises can be visibly kept. "I'll get to it soon" cannot be honored; nobody can point at the moment it came true. "You'll have it Thursday" can be kept in public, and every kept Thursday makes your next sentence cheaper to believe.

The vague promiser never technically breaks their word. They also never bank any credit for keeping it. That is the quiet long-term cost of writing in abstractions: you become someone whose messages are never wrong and never quite needed.

When abstraction earns its keep

Abstraction is honest as a summary of examples you hold, and dishonest as a substitute for them. After three named cases, "the checkout flow confuses new users" is compression. Before them, it is a guess.

So the order matters more than the ratio. Lead with the instance, then generalize if the reader genuinely needs the pattern. Most messages never need the pattern at all; the reader wanted the date and the name the whole time.

The concrete sentence serves the reader

I learned most of this writing the public page for Unvent. Every abstract line I tried, the "write with confidence" kind, died in revision and got replaced by the concrete thing the product does: it rewrites the message you are typing, in the box you are typing it in, in a tone you pick. The abstract lines sounded bigger. The concrete one was the only version a stranger could repeat back.

That trade is in every message you send. The abstract sentence protects the writer, the concrete sentence serves the reader, and each message quietly picks a side. Readers can tell which side you picked. They answer accordingly, or they do not answer at all.