Not Nick Jordan

Where AI slop meets a dumpster fire.

The Engineer's Marketing Problem

The Engineer's Marketing Problem

The Engineer’s Marketing Problem

“Data that works together is closer than you think.”

When I put that headline on our marketing page, I thought it was pretty good. It’s technically accurate. It describes what the product does. It has a little rhythm to it.

It’s also terrible.

Not aggressively bad — just inert. The kind of headline that doesn’t make anyone click, doesn’t make anyone feel anything, doesn’t change how anyone thinks about their problem. It’s the headline equivalent of elevator music: background noise you barely register before moving on.

When I asked for help diagnosing why, the answer landed with some force: it’s vague in the wrong direction. Technical copy fails not because it’s too precise — it fails because it’s precise about the mechanism instead of the outcome. “Data that works together” describes what the product does. It says nothing about what that does for a person who’s drowning in mismatched schemas and missed deadlines.

The kicker was the alternatives. Every option I was offered felt “technical and blah” — and I said as much. Not because the words were wrong, but because I was still asking the wrong question.

The Trap Technical Founders Fall Into

Here’s the thing about building software for a living: you develop an acute sensitivity to precision. You learn to say exactly what you mean, qualify claims carefully, and avoid overpromising. These are engineering virtues. They are marketing liabilities.

Marketing doesn’t reward accuracy about mechanism. It rewards evocation of outcome. Buyers aren’t buying the product — they’re buying the version of their life where the problem the product solves no longer exists. The job of a headline is to make that version feel real and within reach.

“Data that works together is closer than you think” describes the product’s mechanism (data interoperability) and offers a hollow reassurance (“closer than you think”). It addresses neither the pain nor the escape from it.

The technical founder’s reflex when writing marketing copy is to start from the product. What does it do? What are its capabilities? How is it different from the competition? These are the right questions when writing API documentation. They’re almost entirely the wrong questions when writing marketing copy.

The right question is: what’s the specific, concrete frustration that the right customer is sitting with right now, and what does it feel like to have that gone?

What Actually Works (and Why It’s Hard to Write)

Strong marketing copy for technical products tends to do one of two things: it either names the problem with uncomfortable specificity, or it makes the outcome feel viscerally real.

Naming the problem: not “data management is complex” (too vague, too resigned), but “your data team is spending three weeks on every new data partnership, and half of that is figuring out what the other side’s schema actually means.” Now the right person is reading and nodding and slightly embarrassed that it sounds exactly like last month.

Making the outcome real: not “streamlined data operations” (corporate filler) but “a new data partner goes live in a day instead of a quarter.” A specific number changes everything. It’s falsifiable. It implies confidence. It lets the reader do the math on what that would mean for their business.

The reason technical founders find this hard isn’t that they can’t write. It’s that making specific, falsifiable claims about outcomes requires confidence that engineers are trained to suppress. When you know how a system works, you also know all the edge cases, the failure modes, the conditions under which the claim wouldn’t hold. Marketing requires you to commit to the central case and let the caveats live in the contract.

The Feedback Loop That Makes It Worse

Technical products often get built by people who are their own first customers. That’s a strength — the builder deeply understands the problem. But it creates a specific blindness when writing for everyone else.

When you’ve lived the problem, you can hear your own solution even in vague language. “Data that works together” is obvious to me — of course it means normalization, identity resolution, schema matching. I can see through the abstraction to the actual thing.

Prospective customers can’t. They’re reading words, not intentions. And words like “works together” don’t resolve into a concrete image for someone who hasn’t already decided they need what you’re building.

This is why the best marketing review you can get is from someone who doesn’t understand your product and hasn’t heard your pitch. Not because their confusion is correct, but because their confusion is informative. If they can’t construct a specific problem this solves from your headline, neither can your customer.

The Practical Fix

Most technical founders, when told their copy is bad, respond by adding more precision. More detail. More explanation. This usually makes it worse.

The fix is to move the locus of the copy from the product to the customer. Run every headline through one filter: “What does this do for a specific person having a specific frustrating day?” If the answer requires knowing what your product is, the copy is doing the wrong work.

“Data that works together is closer than you think” requires you to already know that data not working together is a problem, already know that this product addresses it, and already believe that the barrier is effort rather than fundamental complexity. That’s three assumptions baked into a nine-word headline — which is three too many if you’re trying to reach people who haven’t already been sold.

The person who should click this headline is a data engineer who just spent two weeks wrangling a feed that should have taken two hours. The headline needs to make them feel seen. Right now, it makes them feel nothing.

That’s the engineering marketing problem in a sentence: precision about mechanism, silence about consequence. Fix the silence.