MVP has become shorthand for "the v1 we'll ship in six months." That's not what it was supposed to mean, and it's why so many founders keep shipping features nobody asked for. The real job of a first release isn't to be minimal. It's to answer a specific question you couldn't answer before you built it.
What viable actually means
The original framing of minimum viable product was about learning. Viable meant "enough of the thing exists that we can observe how people respond to it." Minimum meant "no more than that." Somewhere along the way, viable got redefined as "feature-complete enough to go to market," and minimum got redefined as "whatever we can ship in the first quarter."
Those two redefinitions hollowed out the concept. A modern MVP is often neither minimal nor viable for learning. It's a small product disguised as a hypothesis. The team ships it, users respond, and the team can't tell whether the tepid response is about the core idea or the rough edges of the feature-complete-but-underbuilt version they pushed.
Signal is the product
Reframe the job of the first release. It's not to build something. It's to produce signal that lets you decide what to build next. The product you ship in version one is actually a question presented in functional form.
Two releases that shipped the same features
Team A scoped an MVP around "users can sign up, create a workspace, invite collaborators, and see a dashboard." Four features. Twelve weeks. They shipped it, got some sign-ups, watched most users never return, and spent the next three months debating whether the idea was wrong or the onboarding was wrong.
Team B scoped an MVP around "we need to know whether users will invite a collaborator within seven days of sign-up, because the whole product thesis depends on team adoption." They shipped a cut-down version in six weeks, instrumented the invitation flow, and had a clear answer in two more weeks. Same feature set. Totally different output.
The difference is that Team B shipped to answer a specific question. Team A shipped to go live. Team B spent 8 weeks learning what Team A is still guessing at.
If your first release doesn't answer a question you couldn't answer before, you didn't ship. You published.
The question hierarchy
Every product has a hierarchy of open questions. The top of the hierarchy is existential ("does anyone want this"). The bottom is tactical ("does this onboarding step convert"). The point of each release is to answer questions from the top down, not from the easy-to-build down.
Most teams accidentally work bottom-up. They build the features they can scope and ship, which are usually the tactical ones, because those are easier to estimate. They end up with a beautifully polished onboarding flow for a product nobody has proven they want.
The discipline is obvious in hindsight. Before you ship anything, make the question explicit. Write it down. Name the two metrics that would answer it. Scope the release to move those metrics. Cut everything that doesn't. For the surrounding process, the piece on how founders are de-risking product bets in 2025 walks through the discovery practices that feed this hierarchy.
Cadence is a design decision
How often you ship changes the kind of product you build. Quarterly releases produce one kind of product. Weekly releases produce another. Daily releases produce a third. The best product teams we work with treat cadence like any other product decision.
If your release cadence is six months, you'll design for six months of assumption carry. Every feature you scope has to survive a long period without feedback. That forces over-specification, which forces over-building, which forces the bloat that made MVP a punchline.
If your release cadence is two weeks, the design pressure flips. You scope smaller, you expose assumptions faster, and rework becomes cheap because nothing is over-committed. The plumbing to do this well, especially for AI features, is covered in building LLM features that don't rot.
Cutting scope is a skill
Most product teams are bad at cutting scope. Not because they don't want to, but because the culture around MVP treats cuts as failures. You hear it in the language. "We had to cut that from v1." The framing is apologetic. It shouldn't be.
What good scope-cutting looks like
- Start from the question, not the feature list. If a feature doesn't help answer the question, it's not in v1. No apology required.
- Use the "would I run the experiment without it?" test. If the answer is yes, cut it. You're not saying the feature is bad. You're saying it's not relevant to the learning.
- Pre-commit to what you'd cut. In the scoping doc, list three features you'll cut if the timeline slips by more than a week. Don't wait for the slip to decide.
- Track cut items in a "next answer" list, not a "cut from v1" list. Language shapes behavior. Call them the next things you'll learn, not the things you didn't get to.
Teams that cut well move two to three times faster than teams that don't. And paradoxically, they end up shipping more total features in the same year, because they stopped over-building the early ones.
The only v1 worth building
The only v1 worth building is the one that makes your next decision obvious. If you finish v1 and still don't know whether the product thesis is working, the scope was wrong. Not the features. The framing.
This is why the founders doing this well in 2025 aren't talking about MVPs anymore. They're talking about v1 hypotheses, v2 hypotheses, and the metrics that would tell them they're right. It's less romantic than "our beautiful MVP launched today." It also works.
Team shape matters here too. The teams that can run tight cadence with small releases are usually the ones with embedded senior engineers in the same time zone as the product team. The piece on why nearshore beats offshore covers why that matters more than most founders expect.
Ship the thing that answers the question. Cut the rest. Do it again next sprint. Less mythology, more method.
Metova Editorial is the shared byline for pieces written and reviewed by our engineering, design, and product leadership. Twenty years of building software that ships, distilled into the notes we wish someone had written for us.
