I want to do something more controlled in this one. Instead of doing the full thirty-minute process on a real person, I want to take a single message and show you what it looks like in two versions side by side: the version a competent SDR writes when she has three minutes per prospect, and the version I write when I have thirty.

The prospect is fictional. I'm going to give her enough specificity that the exercise is real — same level of detail you'd see in a brief — but she doesn't exist. I'm doing this on purpose, because I want every claim about the message construction to be defensible, and the only way to keep it defensible is to not pretend a real person produced a real reply.

The prospect.

VP of Engineering at a Series B B2B fintech, about 180 employees. The company sells a treasury management platform to mid-market CFOs. The founder I'm writing for runs a developer-experience consulting practice — helping engineering orgs reduce their internal deployment friction. The match is reasonable: the fintech is growing fast, the engineering team has roughly doubled in 18 months, and the developer-experience problem is a real one at that growth rate.

Now the two messages.

The three-minute version.

The SDR has time to read the VP's LinkedIn bio and skim the company website. The message that comes out the other end looks like this:

Hi [Name],

Hope your week's going well! I came across your profile and noticed you're leading engineering at [Company]. With your team scaling rapidly, I imagine developer productivity and deployment velocity are top of mind.

We work with engineering leaders at high-growth B2B SaaS companies to reduce deployment friction and unlock developer productivity. Our clients typically see a 30-40% improvement in deployment frequency within 90 days.

Would you be open to a brief 15-minute call next week to explore how we might be able to help your team?

Best,
[Sender]

I want to walk through what's wrong with this, because the wrongness is structural and almost nobody talks about it.

Sentence one: "Hope your week's going well." Zero information. The prospect has read this phrase 400 times this year. Her eye skims past it, and now she's reading from a state of low-grade impatience.

Sentence two: "I came across your profile and noticed you're leading engineering at [Company]." This sentence is doing the work of "personalization" but is actually a tell that no real reading has happened. It's the SDR confirming the title that appears in the prospect's headline. The prospect now knows the SDR did, at most, ninety seconds of work.

Sentence three: "With your team scaling rapidly, I imagine developer productivity and deployment velocity are top of mind." This is the worst sentence in the message. It's a guess dressed as a personalization. The phrase "I imagine" is the giveaway. The SDR doesn't know if developer productivity is top of mind. She's guessing it might be because the company is growing. The guess is also the obvious guess — the guess every other vendor in this category is making this week.

Sentence four through six: the pitch. Generic claim, generic proof point (30-40% improvement, no source, no specificity), generic ask. Every word of this section could be in any of fifty other vendors' messages this week. The prospect's pattern-match here is instantaneous.

Sentence seven: "Would you be open to a brief 15-minute call next week to explore how we might be able to help your team?" This is the close that kills the message. "Would you be open" is a question that prompts a no by its structure — the easiest answer to "would you be open" is "no" or "not right now." "Brief 15-minute call" signals that the sender thinks the prospect's time is the friction, when actually the prospect's belief in the sender is the friction. "To explore how we might be able to help your team" is a sentence that says nothing.

This message is competently written. The SDR is not unskilled. The message will reply at roughly 0.4 percent, because the structural problems are upstream of the writing craft.

The thirty-minute version.

Now imagine I'm writing for the same founder, to the same VP of Engineering. I have thirty minutes. Let me walk you through what changes.

First four minutes, her last three LinkedIn posts. She posts rarely — maybe one post every six weeks. But the three most recent posts, across the last four months, are: one short post about a hiring decision (specifically, hiring a Director of Platform Engineering, which is a role her team didn't have before); one longer post about why she changed how her team does on-call rotations; and one technical-but-personal post about a Friday deployment that broke production and what her postmortem process looks like now.

The recurring theme across these three is not "deployment velocity." It's risk. She's writing about platform leadership, on-call burden, and post-mortems. She's preoccupied with the structural ways her team's work creates risk — for themselves, for the company, for the customer.

Next seven minutes, the company. The treasury management platform is in a regulated space. The most recent press release announces a SOC 2 Type II re-certification. The product roadmap, as visible from the changelog, has been increasingly focused on audit and compliance features in the last two quarters. The hiring page has three open roles in security and platform.

The picture is clearer now. The company is moving deeper into regulated workflows. The engineering team is being asked to absorb more risk-bearing complexity. The VP's recent posts are the public expression of how she's thinking about that absorption — through better platform leadership, fairer on-call rotations, more rigorous post-mortems.

Next six minutes, podcast or interview. She doesn't appear on podcasts often. But she did a long-form written interview with an engineering leadership Substack about five months ago. Halfway through the interview, the interviewer asks her what keeps her up at night. She answers: "What keeps me up is that we're growing the team faster than I can build the structural defenses against my own team's growth. Every engineer we add increases the chance that someone, somewhere, doesn't know what they don't know yet."

That sentence is the angle. It is not about developer productivity. It is about her team's structural defenses against the risk that scale itself creates.

I throw out the obvious angles — deployment velocity, developer experience, time-to-merge metrics. Those are all SDR angles. I write toward the structural defenses.

Here's the message at around 70 words:

Five months ago you said the thing that keeps you up is that you're growing the team faster than you can build structural defenses against the growth itself. The on-call rotation post and the new platform engineering hire both look like instances of that — the structural defenses, going in before the next wave of engineers.

The developer experience work I do is downstream of the same problem. Worth a conversation if the timing's right.

What's happening underneath.

Let me walk through this one too.

Sentence one references the long-form interview directly. The reference is specific enough that the VP cannot mistake it for a guess. It also references a sentence she said in passing, five months ago, not a thesis she's been publicly building. The signal is: I read the thing you almost forgot you said.

Sentence two does the work that sentence five normally does. It connects two of her recent observable actions — the on-call post, the platform engineering hire — to the thesis from sentence one. The connection is doing two jobs at once: showing that I read more than one post, and proving the interpretation by showing it predicts her behavior.

Sentence three is the only sentence about the founder's offer. It's framed as "downstream of the same problem," which positions the work as a continuation of what the VP is already doing, not a new project I'm asking her to take on. The framing is critical. She doesn't have time for a new project. She has time for something that extends a structural defense she's already building.

The close is one line. No question. No 15-minute ask. Just a quiet door.

The two messages are about the same length on screen. The first one is 89 words. The second is 71. The difference in word count is small. The difference in what's happening underneath the words is enormous.

What I'd like you to notice is where the work actually lives. It is not in the writing craft. The sentences in version two are not more beautifully constructed than the sentences in version one. Both are competent prose. The work lives in the choice of what to write about. The angle from the interview five months ago is not findable in three minutes. It requires the thirty.

I'd also like you to notice what version two doesn't do. It doesn't compliment the VP. It doesn't claim a benefit. It doesn't quote a number. It doesn't ask for fifteen minutes. It does the thing the prospect's pattern-match is built to detect — it demonstrates real reading — and then it stops, because once the pattern-match has come out right, every additional sentence is risk.

The version one message will reply at 0.4 percent. The version two message, for this kind of prospect, would reply at somewhere between 20 and 35 percent. I'm not going to put a number on it for an invented prospect, because I won't fake a reply rate to make a point. But the gap is roughly that order of magnitude, and the cost of the gap is the difference between thirty minutes and three.

The reading is the work. The writing is what happens after.

Most agencies are selling the writing, which is why most outbound looks like the version one message. The writing is the cheapest part of what we do. The reading is what you're paying for, and it's the part you cannot see in the final output unless someone is willing — like this — to show you the layers underneath.