I Scoped 4 MVPs in 18 Months. Here's How I Learned to Cut Scope Without Shipping Garbage

The first MVP I scoped was a disaster.

I cut everything I thought was "extra." Error handling? Nice-to-have. Onboarding flow? We'll add it later. Clear feedback messages? Users will figure it out.

We shipped on time. Users signed up. And then... nothing. Nobody used it twice. Not because it was missing features. Because it felt unfinished. Half-baked. Like we didn't care.

That was at Sonic Linker, month one. We had three months total to prove the product worked or the company would pivot. I couldn't afford to waste another sprint.

So I changed how I thought about MVPs entirely.

The Real Question Isn't What to Cut, It's What Job You're Solving

Most MVP scoping goes like this: list every feature you want, then start crossing things off until the timeline fits. That's backwards.

I start by writing down the exact job a user is hiring the product to do. One sentence. At Sonic Linker, it was: "Get a personalized landing page link that converts cold traffic without building anything."

Then I ask: what's the absolute minimum set of features where a user can complete that job AND feel like it worked?

Notice I said "feel like it worked." That's the part most PMs miss.

At Sonic, that meant: - Generate a link (obviously) - Customize basic branding (logo, colors) - See if people clicked it - Make the landing page load fast and look legitimate

But it also meant: - Show a loading state so users know the AI is working - Send an email confirmation with the link - Have one clear CTA on the landing page - Let users edit the page after generating it

Those last four weren't "features." They were the difference between something that works and something that feels trustworthy. I didn't cut them.

What I did cut: templates, A/B testing, detailed analytics, team accounts, integrations. All real features. None of them required for the core job.

Quality Isn't About Polish, It's About Completeness of the Core Loop

Here's what I tell people now: an MVP is the smallest version of the product where the core loop is complete, not broken.

At Finvestfx, I was managing a treasury management SaaS for forex teams. We wanted to add a new reporting module. I could've shipped a basic version in two weeks that generated reports but didn't let you filter or export them.

I didn't. Because a report you can't filter or export isn't a report, it's a screenshot. The job isn't done.

Instead, I cut the number of report types from twelve to three. But those three were complete. Filter by date, by client, by product. Export to Excel and PDF. Done.

Users didn't complain about missing report types. They used the three we shipped because they actually worked for their jobs.

That's the shift: I'd rather ship one thing that's complete than five things that are half-broken. It sounds obvious, but when you're under pressure to "move fast," it's easy to forget.

The Framework I Actually Use Now

When I'm scoping an MVP today, I use a simple test for every feature:

Does this feature make the core job possible, or does it make the core job better?

• Possible = must have. You literally can't complete the job without it.
• Better = nice to have. It improves the experience but the job still gets done.

Then I add one more filter:

Does this feature make the product feel trustworthy?

Error states, loading indicators, confirmation messages, undo buttons. These don't make the job possible, but they make users believe the product works. That's not the same as polish. It's baseline credibility.

At Sonic, I cut our initial feature list by 60%. But I didn't touch anything that made the product feel broken or unfinished. And we shipped in three months.

The result? We got our first 50 users in two weeks. They didn't love every feature. But they used it more than once, and that was the whole point.

The One Thing I Wish I'd Known Earlier

MVP doesn't mean shipping something embarrassing. It means shipping the smallest thing that isn't embarrassing.

If you wouldn't use it yourself, your users won't either. And no amount of "we'll add that later" messaging will fix that.

Cut features aggressively. But don't cut the parts that make the product feel real. Because the fastest way to fail isn't shipping late. It's shipping something nobody trusts.