Everyone has a launch plan until you ship it
In the age of vibecoding, it's easy to build a product. It's still hard to build a good product that survives first contact with a user's intent. Read: "Everything starts looking like a toy" #301
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: there’s a new emoji that came out —> a fight cloud! You might wonder how these get approved and created — read more here.
Edition 301 of this newsletter is here - it’s May 4, 2026.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ Everyone has a launch plan until you ship it
“Everyone has a plan until they get punched in the mouth” - Mike Tyson, 1987
People have been paraphrasing Mike Tyson’s boxing quote about about business plans since he said it. If you think it doesn’t apply in software, you need to go through a launch to see it happen.
Take side projects. They sound like a great idea when you talk to Claude (“You’re so insightful!”). If you’re building a product on nights and weekends, you have a plan. You can describe what it does in two sentences. You wrote the landing page, and you are the core user. You believe all of it.
Then a stranger uses the build.
The punch is the moment your code is in someone else’s hands and they’re using it differently than you described it. Every assumption you made about what they’d see, click, expect, miss, or never find is being tested in parallel by people who don’t share your context. The plan was a closed system. The build is an open one.
As a product person, here’s the shift to notice. Before you ship, your bottleneck is the plan. Refining the pitch, the funnel, the deck is where you put your effort.
After you ship, your bottleneck is the loop between the build and the people using it. Most builders never make that transition. They keep optimizing the plan when the plan is no longer the constraint.
What the plan can’t see
From inside the plan, here’s what feels solved:
The user’s intent. You imagined what they need. You wrote copy in their voice — or what you imagine their voice to be.
The funnel. You labeled the steps. You wrote the CTA, the email, the next email.
The pitch. You can describe the product cleanly. Two sentences. Maybe three.
The build. It works on your machine. You’ve used it. It does what it should.
The plan compiles cleanly because there is exactly one judge in the room and they already agree with the verdict. The product feels obvious because you’re the only one who has ever been confused by it, and that was four months ago. You haven’t seen what it look like when you’re not in the room and someone tries it out for the first time.
I spent nights and weekends in February vibe-coding an idea I was sure about. By March I was up at midnight implementing it. By April I’d thrown most of it out and rebuilt it, because the way I was using my own product had drifted miles from the way I was pitching it.
So I rewrote the pitch, fought Apple about a developer account, learned more than I wanted to about packaging Electron apps, put up a landing page, and called it an alpha. Each move felt like progress on the plan. None was a punch. The plan was still inside the plan.
The punch is information, not failure
Tyson’s punch in business usually gets framed as competition or market surprise. In software it’s smaller and more specific. The punch is the gap between what you described and what people actually use.
Another aphorism people often quote about software: “if you’re not embarrassed by what you created, you launched too late.”
Last week, I soft-launched FlowFrame, a tool to shape screen recordings into polished product demos (it’s great for sales walkthroughs, onboarding videos, and tutorials).
Within a day, I realized …
I found a bug in my own licensing service.
Oops, I realized I’d forgotten to ship the tour that’s the entire onramp of the product.
Hey, I rediscovered bugs from March I’d written down and then never fixed.
A temporary solution with loopback audio did not get polished (yet) into an Apple CaptureKit version to capture computer audio.
None of those are failures, exactly. They’re the sound of the punch landing. They’re information that simply wasn’t available to me from inside the plan.
This is what I think people mean when they say the code has escaped your machine. The moment your code is outside your laptop, it starts sending back signal you couldn’t generate yourself. This is also what makes shipping feel scary: the finding out what people think part.
Four PLG lessons that read different after the punch
Here are a few things I’ve learned after (and during) this project launch.
1. Attention is everything — because clarity doesn’t earn the look
You can write a landing page so clean a sympathetic reader could repeat it back to you. Until a stranger has agreed to spend the time to review your information, none of your prose matters. You only learn this after you’ve watched someone bounce.
2. Specific CTAs beat vague ones — because vague CTAs are how plan-writers talk
Inside the plan, “try it, see what you think” sounds inviting. After you’ve asked several people (friendlies) to try your app and haven’t seen their trial emails show up in your metrics, you change the tack. You write clearer instructions like “open the app, drag a screenshot in, click record, send me the link.”
3. Sell outcomes, not features — because features are what the plan is about
Features are how you describe the work to yourself. Outcomes are what the user is about. Once you’ve watched a stranger be politely confused by your feature list, you’ll never write one the same way.
4. Use a critical eye on the product — because you can only see what you meant to build
The plan describes what you meant to build. The gap is invisible from your seat. It surfaces when someone narrates the product back to you incorrectly or finds a weak area that you forgot to fix. You learn the shape of what you built by listening for what people don’t see.
Done is exposure, not completion
Perfect is the enemy of done. What’s less obvious is that the goal of done isn’t completion, it’s exposure. The plan is the warm-up.
After the punch, your operating model is a loop:
Ship — get the build out of your machine.
Watch — observe a real person using it without coaching.
Ask — collect the specific moments they got confused, slowed down, or quit.
Rebuild — change the smallest thing that closes the largest gap, and ship again.
The plan is one node in that loop. The fight is the rebuild of taking the punch and turning it into the next version of the build that survives a real user for a few minutes longer than the last one did.
Most builders don’t believe this when they start.
The plan was the hypothesis, the build is the experiment, and the only data is what comes back through the punch.
So run the loop:
Ship the build before you’re ready.
Pick a CTA so specific you’d be embarrassed to email it to a friend.
Watch one real person use it, no coaching.
Fix the smallest thing that closes the largest gap.
Ship again.
The two-sentence pitch you write after the punch is the one worth keeping. The one you wrote before was a guess.
Everyone has a plan until they get punched in the mouth. That’s not the bad news. That’s the entire job.
What’s the takeaway? If you have a product idea right now and the plan looks airtight, that’s the warning sign. The cleaner it looks from inside, the larger the gap will be when the build finally meets a stranger.
Links for Reading and Sharing
These are links that caught my 👀
1/ The Agent Factory - Ed Sim of Boldstart has been writing (as usual) about agents lately, and his concept of the Agent Factory is really compelling. The Tl;dr —> the way we build software is going to be more about orchestration and shaping features than individual developer efforts. Think Human In The Loop, guiding the AI.
2/ How do you build (collaboratively) with AI - think about the tools required for AI to act without your input, but to achieve deterministic outputs. This looks a lot like building CLI tools (command line interfaces) that enable Agents to use MCP servers to determine the triggers and actions they can access.
3/ Local messaging networks - My worlds are colliding! As I’m thinking about building connected devices via IOT, this messaging protocol comes out. (If you didn’t understand any of those words, this is about creating local networks and messaging among devices.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.