Reid Hoffman’s most quoted line is also his most misunderstood: “If you’re not embarrassed by the first version of your product, you’ve launched too late.” Founders nod along, screenshot it, and then spend nine months building something they’re proud of. That pride is the problem.
The instinct to ship something polished feels responsible. It feels like craftsmanship. But for an early-stage company, a polished MVP is usually a sign you spent months answering questions your customers never asked. You built in the dark and called it diligence.
What “minimum” actually means
The word that trips people up is “viable,” not “minimum.” Founders read viable as “good enough that I won’t be ashamed,” when it really means “just enough to test whether anyone cares.” Those are wildly different bars.
A viable product has to do exactly one thing: let a real person try to get a real job done, so you can watch what happens. That’s it. It doesn’t need settings. It doesn’t need an onboarding flow. It doesn’t need to handle the edge case that keeps you up at night, because you have no users yet, which means you have no edge cases yet.
The classic example is the one everyone forgets the details of. Before Dropbox built anything, Drew Houston made a three-minute video showing how the product would work if it existed. The “product” was a screen recording with a voiceover. It drove their beta waitlist from 5,000 to 75,000 people overnight. The actual syncing technology, the hard part, came after they confirmed people wanted it.
Zappos is the other one. Nick Swinmurn didn’t build a warehouse or negotiate inventory deals. He went to local shoe stores, photographed the shelves, posted the photos online, and when someone ordered a pair, he went back and bought them at retail to ship out. He lost a little money on each sale on purpose. He wasn’t trying to run a profitable store. He was buying the answer to one question, will people buy shoes online without trying them on first? Everything else was a distraction until he knew that.
The real cost of building too much
Every feature you add before launch does three expensive things.
First, it delays the only feedback that matters. Until a stranger uses your product, every decision you make is a guess dressed up as a plan. The longer you build, the more guesses compound on top of each other, and the harder they are to unwind.
Second, it raises the emotional cost of being wrong. A product you built in two weeks is easy to kill or pivot. A product you poured nine months into becomes something you defend instead of test. You start arguing with your users in your head about why they’re using it wrong. Sunk cost quietly turns into stubbornness.
Third, it teaches you nothing about what to build next. The features customers actually want are almost never the ones you predicted. Ship the embarrassing version, watch where people get stuck or excited, and the roadmap writes itself. Build everything up front and you’ve pre-spent your roadmap on assumptions.
How to scope a version you’ll be slightly ashamed of
Here’s a simple filter. Call it the one-job test.
Write down the single most important thing a customer should be able to do with your product. Not the five things. The one thing. Now look at your build list and cross off anything that doesn’t directly make that one thing possible. Auth can be a shared password. Payments can be a Stripe link you send manually. The dashboard can be a spreadsheet you update by hand at night. None of that scales, and that’s fine, because you’re not scaling. You’re learning.
If you’re not slightly nervous to show it to someone, you’ve added too much. A little embarrassment means you stripped it down to the part that actually carries the value. If it feels safe and complete, you’re looking at months of work you did before earning the right to do it.
Manual is your friend here. Doing things by hand that you’ll eventually automate is not a failure of engineering, it’s the fastest way to validate that automating them is even worth it. Plenty of now-large companies ran their first hundred transactions through a founder’s inbox and a Google Sheet.
Ship, then earn the right to build
The embarrassing MVP isn’t about being sloppy. It’s about being honest that you don’t yet know what you’re building, and refusing to spend a year pretending you do. The polish comes later, and it comes informed by reality instead of imagination.
So look at whatever you’re building right now and ask the uncomfortable question: what could you put in front of a real person this week? Not this quarter. This week. Whatever’s left after you answer that is your actual MVP. The rest was always going to change anyway.
Strip it down. Ship the version that makes you wince a little. Then go watch what people actually do.
If you’re trying to figure out which one job your MVP should nail before you build anything else, that’s exactly the kind of clarity Inpaceline OS is built to force. It helps founders pressure-test scope and ship the smallest real thing instead of the biggest safe one. Start at inpaceline.com.
