Most people write the outreach message first. The part that actually matters comes before any of that: who exactly, what signal says they're ready, what's true about their timing right now. Skip it and no amount of clever copy saves you.
A GTM guide has a chapter with this exact title, from someone at Vercel. The ordering argument below comes from there.
The order nobody wants to follow
The sequence matters more than any single step in it.
- Define who you're actually going after — narrow enough to name real accounts, not a broad category.
- Find the signal that says this account is in motion now, not someday.
- Build the timing layer — the thing that tells you when to show up.
- Only then, write the message.
Most people run that backwards, or skip straight to step four. No amount of training or clever phrasing fixes a target list built on guesses — the data underneath the message decides the outcome before the message does.
Tier the list, A through C, and stop spending real effort on C. Don't invent the scoring in a whiteboard session — pull it from the deals that actually closed and work backward. That's ground truth; everything else is a hypothesis wearing a spreadsheet.
What the system is actually made of
"System" sounds abstract until you list what's in it. Five layers, stacked: a scannable summary of who the ICP is, short enough to hold in your head. Deeper context files underneath — signal libraries and battlecards: the objections, the language the account actually uses.
Then reusable skills that work on that context instead of starting cold each time. Documented workflows, so the next attempt doesn't depend on remembering how the last one went. And an archive of what you actually sent, kept next to the context that produced it, so the reasoning doesn't have to be reconstructed from memory later.
Nobody skips the message because they've got nothing to say. They skip the layers under it because those layers are slow, unglamorous, and produce nothing you can point to on day one.
The same failure, smaller, inside my own walls
The same failure shows up one directory over, in my own notes. I keep a running archive of research there — teardowns, video notes, half-formed ideas. Nothing scheduled reads it, nothing routes it anywhere. It grows, but growing isn't the same as compounding.
Knowledge nobody routes isn't a system. It's a pile. You can build a genuinely good outbound system — tiered accounts, real signal, honest timing — and be running the identical failure on your own research, because nobody's watching that side of it. The documented fix is a routing layer: something scheduled that reads new notes and pushes what matters into memory, so the archive stops being a write-only pile.
Watch the few, not the many
Once the system exists, it changes what you watch. Early on, with a handful of real users, the count means almost nothing. What matters is how hard the few you have are using it, and whether that's climbing.
Someone from Granola's team, in the same guide, said it better than I will: "Payment is the consequence. The ruckus is the user's attachment to the product."
Attachment shows up before the invoice does. Watch the wrong end of the pipe and you'll miss it every time.
Fix the bucket before the drip
One more piece: don't scale acquisition on top of a leak. People who were a good fit, signed up, and never came back are the highest-value fix available to you — usually ignored, because reactivation isn't as fun as a new campaign.
Someone at Framer, same guide, put the whole idea in eight words: "Fix the leaky bucket before the drip campaign."
