What MVP Actually Means (And What It Doesn't)

Every time I hear someone describe a half-built product as an MVP, I think about what that word "viable" is doing — or rather, what it's supposed to be doing and isn't.

MVP gets thrown around constantly in product conversations. It's become shorthand for "we're not done yet," a way to set low expectations and ship fast. But that's not what it means, and conflating the two produces products that neither work well nor teach you anything useful.

What "Viable" Actually Requires

Minimum viable doesn't mean minimum. It means the smallest thing that is still genuinely useful to a real user trying to accomplish a real goal.

The minimum part is about scope. You don't build the full feature set. You pick one slice — ideally the core one — and you build that instead. Viable is the constraint that keeps this from becoming an excuse. If someone can't actually use what you built to accomplish something meaningful, it's not viable. It's a prototype, a demo, a proof-of-concept. Those are all legitimate things to build. They're just not MVPs.

The distinction matters because each of these serves a different purpose. A prototype tests a technical assumption. A demo shows what something could feel like. An MVP tests whether real users will use a real thing to solve a real problem. If you call your demo an MVP and put it in front of users expecting MVP-level feedback, you'll get confused by the results.

The Half-Finished Trap

When I started building Composer Catalog, the composer and music pitch management platform I've been developing, I had to be deliberate about this. There were two dozen features I could imagine building: composer profiles, project tracking, pitch history, contact management, submission workflows, reporting dashboards. The temptation was to rough all of them in — get the skeleton up so you could see the full picture.

That approach produces a half-finished product. Every feature is started, none of them work well, and the user experience is fragmented. Worse, you've made a bunch of decisions in each area without the feedback that would help you make them well.

The alternative is to pick one thing, build it completely, and make it good. Not polished in the "spent three weeks on the gradient" sense, but complete in the "it actually works, edge cases are handled, the data model is sound" sense. For Composer Catalog, that meant starting with composer profiles and the core catalog view. Not because those were the most exciting features, but because without them, nothing else was possible. You can't pitch composers you haven't cataloged.

When those features were solid, adding pitch tracking on top of them was faster and produced better results than if I'd built a rough version of both simultaneously.

Where Scope Decisions Get Made

The hardest part of an MVP isn't writing the code. It's the conversation that happens before the code — usually with a client, sometimes with yourself — about what's actually in scope.

I've noticed a pattern in how these conversations go wrong. Someone describes what they want, and then they describe what they also want, and then they describe what would be nice. By the end, you have a feature list that represents everything this product could eventually be, and the conversation hasn't touched on what it needs to be right now for it to be worth building at all.

The question I try to reframe it around is: what does a user need to be able to do for this to be worth their time to try? That's the viable bar. Everything else is roadmap.

This is uncomfortable because it means deferring things that feel important. Reporting is important. Settings are important. Edge case handling for power users is important. But if someone can't complete the core workflow — in Composer Catalog, browsing composers, reviewing their credentials, and initiating a pitch — then none of that other stuff matters yet. Get the core workflow working first.

Minimum Doesn't Mean Cutting Corners

Here's where people get confused in the other direction. Minimum scope doesn't mean minimum quality. You can build a small thing badly or you can build a small thing well. An MVP is the latter.

When I built the Macrolific site, I kept the scope tight. No blog, no case studies, no elaborate animations. Just a clear explanation of what I do, who I've worked with, and how to get in touch. That's it. But the things that were on the site were done properly — the layout was considered, the copy was specific, the performance was good.

I've seen people ship an MVP with broken forms, confusing navigation, and no error handling, and then wonder why users didn't stick around to give feedback. Users don't distinguish between "this is incomplete on purpose" and "this doesn't work." They just stop using it.

The minimum in MVP is about what you build, not how well you build it.

What a Good MVP Actually Teaches You

The point of launching small isn't just to ship fast. It's to learn. A well-scoped MVP gives you specific feedback about a specific hypothesis. A half-finished product gives you feedback about everything and nothing simultaneously.

If Composer Catalog had launched with rough versions of ten features, any problems I found could have come from anywhere. The data model might be wrong. The UX might be confusing. The core premise might not resonate. I couldn't tell. By launching with two features that were done properly, when something didn't work, I had a much smaller space to investigate.

That's the feedback loop an MVP is supposed to create. You're not launching to get users to tolerate your unfinished work. You're launching to test a specific hypothesis with enough completeness that the results are actually meaningful.

Practical Implications

When I'm scoping something now, I try to identify the single workflow that, if it worked well, would make this thing worth using for at least one person. Not a category of person — one specific person with one specific job to do.

Then I build that workflow completely. Not the settings around it, not the reporting about it, not the edge cases that affect 5% of users. The core path. Done properly.

Everything else is next.

That approach has consistently produced better results than the alternative. Not because it's clever, but because it keeps you honest about what "done" means — and that honesty turns out to be the hardest part.