The Framing Problem in Technical Marketing
The first sign I had that something was off was a conversation that went nowhere.
I'd spent about twenty minutes explaining how COS worked to someone who ran demand gen at a mid-size B2B software company. Measurement against peer-reviewed frameworks. The OCEAN model. Five dimensions of communication fit. The validation layer. I walked through the architecture the way I'd walk through it with another engineer — precise, bottom-up, everything in the right order.
She was polite. She asked a few questions that I interpreted as curiosity. At the end she said: "That's interesting. I'll keep it in mind."
I left thinking the meeting had gone okay. It hadn't. She never followed up.
What I didn't understand at the time was that I'd given her a completely accurate description of what I'd built and no reason to care about it that connected to anything she was actually trying to solve. "That's interesting" is what people say when they can't find themselves in what you're describing.
The Accuracy Trap
Technical founders have a particular problem when they write or talk about what they've built.
They optimize for accuracy. Does this description correctly represent the system? Does it capture the key insight? Are the claims technically defensible?
Those are the right questions when you're writing code documentation or a technical spec. They're the wrong questions when the reader is a buyer, a collaborator, a journalist, or an investor.
The buyer's question is not "is this technically sound?" It's "is this relevant to something I'm trying to fix?" Those feel like they should overlap. Often they don't.
When I write about COS, the accurate description is about the measurement methodology — frameworks derived from 860+ peer-reviewed papers, personality-fit scoring, framing analysis. That's what the system is. But most buyers aren't thinking about methodology. They're thinking about a specific, uncomfortable problem: their content isn't landing the way they expected, or deals are stalling, or they can't figure out why the same message works in some accounts and not others.
The accurate description answers a question they're not asking. The useful description has to start from what they're sitting with.
The Mismatch Has a Structure
There's a pattern underneath this, and once you see it you can't unsee it.
Technical founders tend to score high in Openness — the personality dimension associated with intellectual curiosity, comfort with complexity, and genuine interest in how things work at a mechanistic level. When you build something, that orientation is an asset. You think carefully about architecture. You follow implications through. You don't simplify past the point of accuracy.
But Openness-dominant communication is a specific register. It leads with the mechanism. It rewards patient readers who want to understand a system before evaluating it. It implicitly expects the reader to share the same tolerance for complexity, the same interest in "how does this actually work."
Most buyers don't read that way. The people who evaluate new tools — whether they're making a purchase decision, a press decision, or a partnership decision — often operate from a Prevention orientation. They're thinking about risk, about what could go wrong, about how they justify this to their team. They want to understand the problem being solved before they'll engage with how.
When an Openness-dominant founder writes for an Openness-dominant reader, the mechanism comes first. When a Prevention-minded reader encounters that, they disengage. Not because they're unsophisticated. Because the framing never signaled that this was about them.
What Changed When I Stopped Writing for the Reader I Wished Existed
The shift wasn't a copywriting trick. It was a sequencing change.
The original version of COS marketing started with what the product does. The measurement layer. The frameworks. Then, eventually, the problem it solves.
I flipped it. The new version starts with the situation a buyer is already in: you've spent real money on content, the metrics look fine, but deals aren't closing the way they should and you can't point to why. Then it introduces the idea that communication has structure that can be measured. Then the methodology.
Same information. Different order. Very different conversations.
The first conversation where I tried the flipped version, the buyer interrupted me three minutes in with a specific situation from her own pipeline. She wasn't waiting to ask. She'd already found herself in the description. That's the tell — when the reader starts contributing examples before you've finished explaining, the framing is working.
It happened again with a press conversation. The reporter's first question with the old framing was usually something about the competitive landscape. With the new framing, the first question was about a specific use case they wanted to understand better. Those are completely different stories.
The content didn't change. What changed was whether the reader could see the door before I explained how the room was built.
This Isn't Just a Founder Problem
I've seen the same pattern from PMs writing release notes, engineers writing internal proposals, and analysts writing reports for non-technical stakeholders.
The writer knows the material. The reader doesn't need to understand the material at the same depth to make a decision. But the writer builds the explanation from the inside out, starting from what they know, ending at the takeaway, in the order that makes sense to someone who already understands the system.
The reader needs the takeaway first. The context second. The mechanism only if they're still interested by then.
Every time you write something technical for a general audience and wonder why it didn't land, the answer is probably sequencing, not substance. You wrote for the reader who needs to understand what you built. The actual reader needed to know whether it matters to them before they were willing to learn what it is.
The Real Constraint
Here's the thing that took me a while to accept: the reader's cognitive style is not a failure on their part. It's the constraint the communication has to work within.
When I write for the reader who already cares about peer-reviewed frameworks, I'm writing for the reader I find most interesting, not the reader who is most likely to be in front of me. That's an understandable bias. It's also a reliable way to produce content that sounds impressive and doesn't move anything.
The actual job is to write for the reader who exists: someone with a specific problem they're already carrying, a limited appetite for mechanism before relevance, and a decision to make that isn't about whether my methodology is correct.
That reader needs to see their problem in the first paragraph. They need to understand why this connects to something they care about before I ask them to learn how it works.
Accuracy is not the goal. Accuracy in service of relevance is.
More in the builder series: What I Learned Building Solo AI Tools: On Limits and Leverage (August 3) and Nightwatch: What I Built When I Needed Someone to Work While I Sleep (July 30).