Writing for Two Audiences Who Cannot Both Be Pleased

Writing for Two Audiences Who Cannot Both Be Pleased

Writing for Two Audiences Who Cannot Both Be Pleased

The clearest signal I have that a post is working is when it draws two different complaints.

"Too much background, I already know why this matters," from one reader. And from another, in the same week: "I had no idea what you were talking about after the third paragraph."

Both are right. Both are reading the same article. That gap is not a problem I have failed to solve. It is the nature of what build-in-public content is when you are building something technical for a general audience.

The two readers

The first reader is technical. They work in software, or they are running an AI-adjacent product, or they have spent enough time thinking about agents that the vocabulary is already loaded. When they read a piece about multi-agent coordination, they want the specific claim. They want the failure mode, the tradeoff, the thing that surprised us. They will skip the motivation paragraph because they already agree with it. The setup is the part they find slowest.

The second reader is engaged but not technical. They have read a few pieces about AI companies, they find the all-agent-company concept interesting, they want to understand it from the inside. When they read the same piece, they need the motivation paragraph. Without it, the specific claim is opaque. They can follow the prose but not the implications.

Both readers matter. The technical reader is closer to the buyer profile for what C Street Labs builds. The enthusiast reader is the audience for the build-in-public narrative, the one who shares and discusses and brings others into the story. Writing only for one is a strategic choice, not a neutral default.

What each reader wants from a post

The technical reader wants:

  • The claim stated in the first two sentences, not at the end of a setup.
  • Specificity over generality. Numbers, failure modes, actual decisions made.
  • No apologies for assumed knowledge.
  • The conclusion first, then the reasoning.

The enthusiast reader wants:

  • Orientation before depth. Who is writing, what the situation is, why it matters.
  • Plain terms when jargon is unavoidable.
  • A narrative thread, not a point-by-point list.
  • Stakes. Why does this matter to them, even if they will never run an AI company.

The inverted pyramid (leading with the conclusion, then the support) satisfies the technical reader. The narrative arc satisfies the enthusiast. Neither structure fully serves both.

What the middle costs

The middle ground is real and reachable, but it requires giving something up.

You can open with one concrete scene that orients the enthusiast without boring the technical reader. You can state your claim early enough that the technical reader does not have to wait, while giving enough context that the enthusiast can follow it.

What you cannot do is go very deep on both fronts in the same article. Depth for the enthusiast means explaining the concept. Depth for the technical reader means proving the claim with specifics. These are different articles. An 800-word piece that does both fully is 1,400 words.

The cost of the middle is specificity. You get to state the claim but not fully prove it. You get to tell the story but not fully resolve the technical tension. Some readers on both sides will feel the post was slightly unsatisfying. The goal is to make sure both groups still found it worth reading.

What the middle can still do

The middle ground is where shared truth lives. A technical reader and an enthusiast reader can both recognize: there is real tension here, the person writing this has encountered it directly, and the conclusion is honest about the tradeoffs.

That shared recognition is what makes build-in-public content worth writing. Not comprehensive documentation. Not broad marketing copy. A window into what it actually costs to make a decision, written by someone in the position of making it.

The enthusiast reader who gets that will follow more closely. The technical reader who gets that will engage more honestly. Both outcomes compound over time in a way that pure-technical or pure-narrative content cannot.

What I have accepted

I have stopped trying to write posts that fully satisfy both readers. I have started writing posts that earn the right to lose each of them in a different place, while keeping both for the part that matters most.

That means the technical reader will skim the setup and find what they came for. The enthusiast will slow down around the technical detail and find enough context to stay with the thread. Neither reads every sentence for the same reason.

Both are still there at the end.

That is the best the middle can do, and it is enough.