What Is a Single-Feature MVP? Definition + Example
A single-feature MVP is a first release that builds only the one core feature carrying your central value hypothesis — and nothing else. You strip the product to the single capability that must work for customers to care, then ship it to test whether that value drives the behavior you're betting on.
Quick Answer: A single-feature MVP ships only the one feature that delivers your product's central value, leaving out every supporting feature you might eventually want. The goal is to test the riskiest, most valuable job — does this capability resonate and drive the key behavior — with the smallest possible build, before you invest in the rest.
Most first products fail not because they lacked features, but because the one feature that mattered never proved its value. A single-feature MVP forces that test early. It is a discipline as much as a build strategy: choose the one job worth testing, ship it well enough to show value, and resist the temptation to add more.
How a Single-Feature MVP Works: One Core Job, Nothing Else
A single-feature MVP works by isolating the one capability that carries your value hypothesis and building only that, so the customer's reaction is a clean signal about the value itself.
It tests the riskiest, most valuable assumption first. Testing Business Ideas frames MVP work as a hunt for the assumption that will kill your business if it's wrong. The single feature should answer one question: will customers get real value from the core thing this product does? Everything else waits until that answer is yes.
It trades breadth for a clean read. Because only one feature exists, you can attribute any usage or retention directly to it. A broader build muddies the signal: you can't tell whether people stayed for the core value or some peripheral convenience. For what qualifies as a minimum viable product at all, see what an MVP actually is.
It demands ruthless scope-cutting. The hard part isn't building the feature — it's refusing to build the ten others that feel necessary. Every cut is a bet that the core value can stand on its own, and that discipline separates a single-feature MVP from a thin version of the full product.
A Concrete Single-Feature MVP Example
A single-feature MVP example is a scheduling tool that launches with only the ability to share a link that lets someone book a time on your calendar — no team features, no reminders, no payments, no branding.
The one feature carries the whole value promise. The central hypothesis is that people will pay to stop the back-and-forth of scheduling. The single feature — pick a slot, book it, done — tests exactly that. If people share the link and bookings happen, the value is real. If they don't, no amount of reminders saves it.
Everything deferred is genuinely deferred, not faked. Reminders, group scheduling, and calendar sync are plausible features, but none is the reason someone would adopt the tool on day one. They wait until the core booking behavior is proven. The pattern is illustrative, not a claim about any specific company.
The risk lives in going too bare. If the booking flow is so stripped that it's confusing or breaks on a real calendar, the test fails for the wrong reason — bad execution, not absent value. The one feature must still do its job well enough to be judged fairly.
Single-Feature MVP vs Full MVP: A Comparison
The table below contrasts a single-feature MVP with a broader first release across the dimensions founders weigh when deciding how much to ship. It is a qualitative comparison.
| Dimension | Single-Feature MVP | Broader First Release |
|---|---|---|
| Scope | One core capability only | Several connected features |
| What it tests | Whether the central value resonates | Whether a fuller workflow fits |
| Signal clarity | High — usage maps to one feature | Lower — value is spread across features |
| Build discipline | Ruthless cutting required | Prioritization across a set |
| Main failure mode | Feature too bare to show value | Effort spread thin, core value untested |
| Best when | One assumption dominates the risk | Value depends on features working together |
Takeaway: A single-feature MVP is the right call when one assumption carries most of the risk and a single capability can demonstrate the value on its own; a broader release makes sense only when value genuinely emerges from features working together. To see where this sits among other approaches, compare the types of MVP.
How to Choose the One Feature to Ship
Choose the one feature by finding the intersection of highest value and highest risk — the capability customers would miss most, and the one you're least certain they'll adopt.
Name the value hypothesis in one sentence. Write the core belief: "Customers will do X because our product lets them Y." The one feature is whatever is required to make Y possible. If a feature isn't needed for that sentence to be true, it's not the one.
Pick the riskiest, most valuable job — not the easiest. Founders often ship the feature that's simplest to build rather than the one that proves the most. Reverse it: isolate the feature whose failure would sink the product, because that's the assumption you most need to test. This is the same logic behind building toward product-market fit rather than shipping activity.
Cut everything that merely supports the core. Onboarding flows, dashboards, settings, and admin tools are supporting cast. Strip them until only the value-carrying feature remains, then check that what's left still completes its job end to end for a real user.
Guard against the too-bare trap. Ruthless cutting has a floor: the feature must still deliver its value convincingly. If removing one more thing would make the core job confusing or unreliable, you've hit that floor — ship there, not below it. A tool like Edmired can help you frame the test, but where the floor sits is your judgment.
Key Takeaways
- A single-feature MVP builds only the one core feature that carries your value hypothesis — and deliberately nothing else.
- The purpose is to test the riskiest, most valuable assumption cleanly, before investing in supporting features.
- Its defining discipline is ruthless scope-cutting, not clever engineering — the hard part is refusing to add more.
- Choose the feature at the intersection of highest value and highest risk, not the one that's easiest to build.
- The main danger is going too bare — a feature so stripped it can't demonstrate value fails the test for the wrong reason.
- Use it when one assumption dominates the risk; prefer a broader release when value depends on several features working together.
Frequently Asked Questions
Is a single-feature MVP the same as an MVP?
Not exactly. An MVP is any smallest build that tests a value hypothesis; a single-feature MVP is one specific form — the version that isolates a single core capability. Other MVP types test value differently, some without building a working feature at all. It's a narrow, high-focus subtype rather than a synonym.
How do I know which feature to build first?
Find the feature that is both most valuable and most uncertain — the capability customers would miss most and the one you're least sure they'll adopt. Write your value hypothesis as one sentence and keep only what's required to make it true. Build that, cut the rest, and treat the feature as an experiment.
Can a single-feature MVP be too minimal?
Yes. If you cut so deep that the one feature is confusing, unreliable, or can't complete its job for a real user, the test fails because of bad execution rather than absent value. Ruthless scope-cutting has a floor: the feature must still do its job well enough to be judged fairly.
When should I choose a broader MVP instead?
Choose a broader first release when the value genuinely emerges from several features working together, so no single capability can demonstrate it alone. If your core value depends on a connected workflow rather than one standout job, a single-feature build would test something incomplete and mislead you.