Somewhere between the pitch deck and the actual product there's a gap, and before you have real customers that gap is enormous. The roadmap says the feature exists. The changelog says it shipped last Thursday and broke on Friday and got pulled. Writing a cold email during this stretch means choosing, every time, between describing the product honestly, which undersells what you're building toward, and describing the plan, which oversells what a stranger can actually click on today. Most founders default to the second option without quite admitting that's what they're doing, and it catches up with them on the first real call.
Selling the roadmap is a lie with a delay on it
It doesn't feel like lying at the time. You genuinely believe the feature will exist by the time the deal closes, so describing it in the present tense feels like a rounding error, not a deception. The buyer doesn't experience it that way. They booked a call, or worse, started onboarding, expecting something specific, and the gap between what was described and what's actually there becomes the first thing you have to explain, on the call where you were trying to build trust, not spend it. A prospect who catches the gap once will re-read everything else you told them with more suspicion than they had before, and they'll be right to.
Sell the direction, not the feature list
The fix isn't to describe the product more modestly. It's to describe something different: the direction and the problem, rather than a checklist of capabilities that might not be true by the time they check. "We're building the tool that stops your team reconciling this by hand" is true today and will still be true after next week's release, regardless of exactly which screen does it. "It automatically syncs across all four of your systems in real time" might be true today, might be true in three weeks, and might quietly become "in most cases" after an edge case shows up in week two. Write the sentence that survives the roadmap changing, and let the specific mechanics come out on the call, where you can actually say what's true right now instead of committing it to writing before you're sure.
Say out loud that it's early, and mean it as a reason to talk, not an apology
The instinct is to hide how new the product is, on the theory that "early" reads as risky. For the right person it reads the opposite way. Someone who's actively frustrated by the current options isn't looking for the safest, most finished vendor; they're looking for someone who'll actually build the thing they need instead of shipping them a feature request that goes into a backlog nobody prioritizes. Say plainly that you're new, that the product is genuinely still moving, and that this is exactly why their input right now would shape something rather than get filed away. That's not a weaker pitch than pretending to be established. For a certain buyer, at this exact moment, it's a stronger one, and it happens to be true.
Optimize the send for what you learn, not for what it closes
Before the product is stable, the right metric to watch isn't reply-to-close. It's what the replies actually say. A batch of outbound that gets a handful of "not interested, we already use X" is more valuable to you right now than a batch that gets three enthusiastic "sounds great, send me a link," because the second batch tells you people liked the words and the first batch tells you what's actually in the market you're up against. Write with that in mind: ask a real question instead of pushing straight to a demo link, and read every reply for the sentence they used to describe their own problem, because that sentence is worth more to your next fifty emails than any subject-line test.
This changes what a good outbound message looks like at this stage. Less "here's what we do," more "is this the actual shape of your problem, and if not, what did I get wrong." You're not trying to close the first batch. You're trying to find out whether the thing you're building matches what people actually have, and a message built to extract that answer looks different from one built purely to book a meeting.
Rewrite the message the same day the product changes
One real advantage of doing outbound yourself, or with something that lets you edit it in minutes, rather than handing a sequence to an agency or locking it into a separate sending tool somebody set up weeks ago: when the product genuinely changes, the message can change the same afternoon. Rocketship writes the outbound from a plain description of the buyer and the problem, which means when the roadmap shifts, you rewrite that description and the next batch reflects it immediately, instead of a stale sequence running for another two weeks describing a feature that no longer works the way it's written. It also sorts the responses for you and surfaces the ones worth answering, so you're not wading through "unsubscribe" and "already have something for this" by hand while you're also shipping the fix that changes what you'll say next week.
Searching for the right people and seeing them by name costs nothing before you commit, and Launch itself starts at $24.99 a month once you're ready to send, which matters here specifically because the product moving fast means the message needs to move with it without a big new expense every time it does.
What you're actually testing right now
You're not testing whether this exact version of the product converts at scale. You're testing whether the problem is real, whether your words for it land, and whether the direction you're headed matches something people are actually frustrated about today. Write outbound for that question, tell people plainly that things are still moving, and let the roadmap catch up to what the replies tell you, instead of writing the replies a check the roadmap hasn't cashed yet.