A founder I was talking to recently described his situation this way:
“I can build, design, and ship a product all the way to launch-ready. But when it’s time to actually activate — cold outreach, Reddit posts, email sequences, getting the first users — I stall. Every time.”
He went on to say something I thought was unusually self-aware:
“The building phase has clear feedback loops. Marketing feels open-ended and harder to decompose into real tasks, so I drift back to building instead. I know the fix intellectually. I just keep not doing it.”
He’d shipped three products in a year. None of them had users. He wasn’t lazy. He wasn’t confused about what needed to happen. He was stuck in a pattern he couldn’t break.
I’ve watched this pattern play out enough times — in founders I’ve worked with and in myself — that I now think it’s the single most common failure mode of technical founders at the early stage. It is more common than building the wrong thing. It is more common than running out of money. It is the post-ship cliff, and most technical founders are sliding off it right now.
I want to write about why it happens, why the standard advice fails to fix it, and what I’ve seen actually break the pattern. This is going to be a long piece because the problem deserves more than a platitude.
The Pattern, Named
Here is the cycle, in its most recognizable form:
You spend two to six months building something. You’re in flow. The work is hard but it’s the kind of hard you know how to handle. Code compiles. Tests pass. Features ship. You make decisions all day and you can tell, by the end of each day, whether you made progress.
You hit launch. You deploy. The product is live.
For maybe 48 hours, you feel triumphant.
Then you sit down on Monday morning and the question hits: what do I actually do today to get someone to use this?
And the answer is unclear. You could post on X. You could write a blog post. You could cold email some people. You could go on Reddit. You could build a landing page. You could redesign the landing page. You could record a demo video. You could do all of these things and have no idea whether any of them is the right thing.
So you open the codebase. There’s a bug you noticed last week. There’s a feature you’ve been meaning to polish. There’s a refactor that would make the next release smoother. Within an hour, you’re back in the work that has clear feedback loops. You tell yourself you’ll do the marketing thing later. You feel a small sense of relief.
A week passes. A month. The product is technically better than it was at launch. It still has no users.
This is the cliff. It’s not a one-time event. It’s a recurring slip. And every time the founder slips, it gets easier to slip again, because the codebase is now a more comfortable place to hide than it was last week.
Why the Standard Advice Fails
The standard advice given to founders in this situation is some version of “just do it.” Pick a channel. Send the emails. Post the thing. Stop overthinking.
I want to be honest: this advice is not wrong. It’s just useless. Telling a founder who has been stalling for three months to “just do it” assumes the problem is informational. It isn’t. The founder already knows they need to do it. They have read the books. They have watched the videos. They have nodded along to the podcasts. The knowledge is not the bottleneck.
The bottleneck is the shape of the work.
Building has a shape that engages the part of a technical founder’s brain that has been trained to do hard things. It’s discrete. Each task has a beginning and an end. Progress is measurable in concrete units — features shipped, tests passing, bugs closed. The dopamine arrives reliably. The work feels like work in a way the founder recognizes.
Marketing, at least the way most founders imagine it, has a fundamentally different shape. It’s not discrete. “Get users” is not a task; it’s an outcome. The work that produces the outcome is fuzzy, ambiguous, and feels open-ended in a way that triggers a very specific kind of avoidance. The founder doesn’t know when they’re done. They don’t know if they did it well. They might do everything “right” and get no response, which feels worse than not trying — because at least if you don’t try, you can tell yourself you would have succeeded if you had.
So “just do it” doesn’t work, because the problem isn’t motivation. The problem is that the work, as the founder currently conceives of it, does not have a shape they can execute against.
The fix is not to push harder on the same conception of the work. The fix is to change the shape of the work itself.
The Reframe That Actually Helps
Here is the single most useful reframe I’ve found, and I want to state it as plainly as I can:
This sounds abstract. Let me make it concrete.
A founder who tells me “I need to do marketing this week” is, almost without exception, going to stall. The task is too fuzzy. There’s no point at which they can declare it done. There’s no checkbox to tick.
A founder who tells me “I need to identify 20 specific people by name who have this problem, find their LinkedIn URLs, and draft a personal opening line for each of them by Wednesday” is going to execute. That task has the same shape as the work in their codebase. It’s discrete. It has a clear definition of done. It produces an artifact you can look at.
The two founders are doing the same underlying work. The first one is trying to “do marketing.” The second one is doing a build task that happens to be in a marketing system.
Once you see this, you can start designing the post-ship phase the same way you designed the build phase. The build phase had a backlog. It had sprints. It had a clear definition of what “done” meant for each task. Why does the post-ship phase not have the same?
Most founders, when I push them on this, can’t give a good answer. They just never set it up that way. They treated building as engineering and treated marketing as vibes. So they got engineering results from the engineering work and vibes results from the marketing work.
What “Activation as a System” Actually Looks Like
I want to walk through what this looks like in practice, because I think the abstract version of this advice gets nodded at and not used.
Imagine it’s Monday morning of week one after ship. Here’s what I’d want a founder to have set up before lunch.
A pipeline of targets. Twenty specific named humans, with their roles and companies, who you genuinely believe have the problem your product solves. Not “marketing teams.” Not “B2B SaaS founders.” Twenty actual people, by name, in roles you’ve thought about. This is a build task. It has a definition of done. You either have 20 names by lunch or you don’t.
A daily conversation target. Not a vague intention to “reach out to people.” A specific number — usually 5 to 10 personal outreach messages per day, sent by hand, not by a tool. The metric is messages sent, not responses received. Why? Because responses are not under your control. Messages sent are. Building the habit around the controllable variable is the only way the system survives the inevitable stretch where you send 30 messages and hear nothing back.
A weekly conversation target. Of the 5 to 10 daily messages, you’ll get some response rate. Translate that into a weekly target for actual conversations. Three calls a week is a reasonable starting point. Five is better. The number itself is less important than the fact that there is a number and you know whether you hit it.
A Kanban for outreach. Yes, literally. Columns for “to research,” “to message,” “messaged — waiting,” “responded — to schedule,” “scheduled,” “called — to follow up,” “follow up sent — waiting.” Every prospect moves through the board the same way a feature moves through your dev board. You look at it every morning. You move things across columns. You feel the same small dopamine hit you feel when you close a ticket.
A weekly review. Friday afternoon, half an hour. You look at: how many messages did I send? How many calls did I do? What did I hear that I didn’t expect? What pattern is emerging? What’s the one change I should make to the outreach for next week? This is a retro. You’ve done retros before. Same shape.
If you set this up before lunch on Monday of week one, the post-ship cliff disappears. Not because the work is easier. The work is exactly as hard as it always was. The cliff disappears because the work now has the same shape as the work you’re already good at. There’s a backlog. There are tasks. There’s a definition of done. There’s a daily and weekly cadence. There’s a place to feel progress.
You haven’t transformed yourself into a marketer. You’ve transformed the marketing into a thing a builder can build.
The Trap Inside the Reframe
I want to flag a failure mode I see when founders take this advice, because it’s worth naming.
The failure mode is: the founder hears “make marketing into a system” and immediately spends the next two weeks building the system instead of doing the work. They set up a beautiful Notion. They evaluate seven CRM tools. They build a custom outreach tracker. They write a manual for how the system will work. They make a dashboard.
This is the cliff in a new costume. The system-building has all the same properties as the product-building it replaced — discrete tasks, clear progress, the satisfying click of work that feels like work — except now you can do it indefinitely without ever sending an outreach message.
If you find yourself doing this, stop. The system I described above should take roughly four hours to set up. A Google Sheet works. A Trello board works. A piece of paper works. The point is not the tooling. The point is that the work has shape. You can give yourself shape with the cheapest possible tool. If you’re spending more than half a day on the system before you’ve sent your first message, you’ve replaced one form of avoidance with another.
The metric I’d hold yourself to: by end of day Monday in week one, you should have sent at least three real outreach messages to real humans. Not “drafted.” Not “queued.” Sent. If you haven’t, you’re not actually executing on the system. You’re decorating it.
The Conversation You’re Avoiding
I want to be direct about the deepest reason this pattern holds, because the tactical reframe above only works if you also see the emotional one.
The reason a technical founder defaults to building instead of marketing is not, fundamentally, that marketing is fuzzier. Plenty of fuzzy things engage technical founders. Game design is fuzzy. Research is fuzzy. They engage with those.
The reason is that marketing, done correctly, eventually requires you to put your work in front of a specific human who has not agreed to like it, and absorb their reaction in real time. That human might say no. That human might say “I don’t get it.” That human might say “this is fine but it’s not a priority right now.” Those things are hard to hear after three months of building, and they’re hard to hear in a way that “the tests are failing” is not. Failing tests aren’t personal. The product you spent three months building being shrugged at by a real human is personal, whether you intend it to be or not.
So the avoidance isn’t intellectual. It’s protective. The codebase is a place where you can do hard work without the kind of feedback that hurts. The outreach world is a place where the feedback can hurt.
I don’t think there’s a way around this. I’ve watched a lot of founders try to find one. The agent stack is one attempt at it — you can run a campaign and get rejections at scale without ever having to feel any of them personally. It doesn’t work, because the rejections at scale don’t teach you anything; the rejections you feel are what teach you. The other attempts are subtler — running through “marketing” channels that have no human on the other end (SEO, ads, content), avoiding calls in favor of email, treating every conversation as a transaction rather than an exchange. They all share the same structure: do the form of marketing without the substance, because the substance is the part that’s emotionally costly.
The founders I’ve watched break the pattern are the ones who accepted that the discomfort is the work. Not a phase to push through. Not a sign you’re doing it wrong.
The system I described above doesn’t remove the discomfort. It just gives you something to hold onto while you do the uncomfortable thing. The Kanban doesn’t make rejection feel better. It just makes sure you keep moving the next prospect to the next column anyway.
A Last Note on Speed
I want to close on something I’ve changed my mind on.
For a long time I thought the right answer to the post-ship cliff was to give founders permission to take their time. Marketing is hard. The pattern is real. Be patient with yourself.
I don’t think that anymore. The post-ship cliff is dangerous specifically because of how it interacts with time. Every week you stay on the cliff, the codebase grows, the cliff gets a little more comfortable, and the version of the product you’re trying to sell drifts further from anything a real user has touched. Six months in, you don’t just have a marketing problem. You have a product that’s been built without customer contact for half a year, which is a much harder problem to fix than the marketing one was.
The right answer is not patience. The right answer is to set up the system the week you ship, and start moving prospects across the board on day one. Not because it’s easy. Because the cost of not doing it compounds in a way that gets very ugly very quickly.
You will not feel ready. The system will feel awkward. The first outreach messages you send will feel embarrassing. You will look at the Kanban on Friday and feel like you didn’t do enough.
Do it anyway. Move the cards anyway. Send the messages anyway. The cliff doesn’t go away because you avoid it. It goes away because you walk down it, one slow uncomfortable step at a time, until you reach the part of the journey where you’ve talked to enough humans that you know what you’re actually building.
That part is on the other side. The only way there is through.
Filed under: GTM