Product Prototyping - Single Feature MVP
In Brief
A single feature MVP is a working product that delivers exactly one core feature — polished, functional, and complete — while deliberately excluding everything else. The hypothesis is simple: does this one feature provide enough value on its own to attract and retain users? If users come back for a product that does only one thing, that one thing is genuinely valuable. If they do not return, no amount of additional features will save it.
This is not a rough prototype or a half-built product. The single feature should work reliably and provide a good user experience. The constraint is scope, not quality. Everything outside the core feature is intentionally absent to isolate the variable being tested.
Common Use Case
You have already validated the problem and a candidate solution through lower-fidelity work — interviews, paper prototypes, or a clickable prototype — and the team is ready to build code. You want a clean read on whether the core value exchange is strong enough to retain users on its own, before you spend months adding the surrounding product. You will accept that the result is a real product in front of real users, with all the operational weight that implies.
Helps Answer
- Is the core feature valuable enough to attract users on its own?
- Will users return to a product with only one feature?
- Which user segments find the core feature most valuable?
- What is the natural retention curve for the core value proposition?
- What complementary features do users request most urgently?
Description
The single feature MVP tests the most fundamental product question: is the core value proposition strong enough to stand alone? Many products fail not because they lack features but because their core feature is not compelling enough. By stripping away everything except the core, you get an unambiguous signal about whether you have found genuine value.
The deliberate exclusion of secondary features is a feature of this method, not a limitation. When users have only one thing to do, their behavior around that one thing becomes extremely clear. You see exactly how often they use it, how long they spend, whether they return, and what they try to do next (which tells you what to build second).
What to Build
Choose the single feature that represents the core value exchange — the one thing that, if it works, makes the product worth using even without anything else. This is usually the feature that:
- Directly addresses the validated customer problem.
- Provides value the first time it is used (not after extensive setup or data accumulation).
- Can be explained in one sentence.
- Is clearly differentiated from existing alternatives.
What Not to Build
Deliberately exclude:
- User profiles and social features (unless that IS the core feature).
- Settings and customization.
- Onboarding flows beyond the absolute minimum.
- Analytics dashboards.
- Secondary use cases, even if they seem easy to add.
- Administrative tools (handle admin tasks manually).
How to
Prep
- Identify the core feature. Review your solution interviews, prioritization exercises, and prototype tests. Which single feature generated the strongest positive signal? If there is disagreement on the team, that is a sign you need more research, not a compromise feature.
- Define the scope ruthlessly. Write a one-sentence description of what the MVP does. If the sentence contains “and,” you have too much scope. Cut until it is a single capability.
- Pick the retention window before you build. Decide up front whether your product is daily-, weekly-, or monthly-use, and which of D1 / D7 / D30 retention is the primary success metric. Picking afterward is how teams rationalize disappointing results.
- Define the acquisition channel. Choose one channel — direct outreach to research participants, a landing page, a targeted community post — and write the one-sentence pitch. The channel and pitch shape who shows up and what they expect; mismatches show up later as low retention.
- Instrument before you ship. Wire up retention analytics (Mixpanel, Amplitude, PostHog) before launch. Capture every session, every action on the core feature, and a single open-ended “what did you wish this could do?” prompt for retained users.
Execution
- Build for quality within the scope. The single feature should work reliably, load quickly, and provide a good experience. Invest the time you saved by cutting scope into polishing the core feature.
- Ship to real users. Release the single feature MVP to a small group of target users (50 to 200 is sufficient for initial retention data). Use the simple acquisition channel you defined in Prep.
- Watch the first week live. Sit with the data daily for the first week. Bugs in the core feature will surface fast and they will distort retention if you do not catch them. After the first week, drop to a weekly cadence and let the retention curve develop.
- Listen for feature requests but do not act. Track what users ask for most urgently and most frequently. Do not ship any of it during the test window. The whole point of the method is to measure retention against the bare core; adding features mid-test destroys the read.
- Capture departure signal. When a user stops returning, send a one-question email: “What were you hoping to do that you couldn’t?” The reasons people leave are at least as informative as why people stay.
Analysis
- Read the retention curve first. Plot D1, D7, and D30 retention. The shape matters more than any single number — a curve that flattens at a low percentage is genuine value with a small audience; a curve that goes to zero is the feature failing regardless of how high D1 was.
- Compare against the metric you picked in Prep. D1 above 40%, D7 above 20%, D30 above 10% are usable thresholds for daily-use products; weekly- and monthly-use products will look different and need to be judged against their own use frequency. Honor the metric you committed to before you saw the data.
- Segment retained vs. churned users. Compare demographics, acquisition source, and first-session behavior. Patterns in the retained cohort tell you who the real customer is — which may not be who you targeted.
- Cluster the feature requests by retained users only. Requests from users who are still using the product carry far more signal than requests from users who never returned. The top 2 or 3 clusters from retained users are the candidate second feature.
- Decide the next move. One of three things should happen: retention curve flattens at a usable level → keep building, the second feature is the top retained-user request; retention curve is borderline → narrow the audience and re-run before adding scope; retention curve goes to zero → do not add features, revisit the core value proposition.
- Survivorship bias Users who stick with a single-feature product are self-selected enthusiasts. Their behavior may not represent the broader market. Track not just retained users but also why departing users left.
- Novelty effect Initial usage may be driven by curiosity rather than genuine value. Wait for the retention curve to stabilize (usually 2 to 4 weeks) before drawing conclusions.
- Scope creep temptation The hardest part of a single feature MVP is maintaining discipline about what NOT to build. Every feature request feels urgent. Resist until retention data confirms the core feature works.
- Confounding acquisition If users arrive with incorrect expectations (because of marketing messaging or channel context), low retention may reflect expectation mismatch rather than low feature value. Ensure your acquisition channel accurately describes what the product does.
- Vanity-metric substitution Signups, satisfaction scores, and session counts are easier to look at than retention and usually look better. Pick the retention metric in Prep and refuse to substitute later.
Learn more
Case Studies
Foursquare
Launched in 2009 with one feature: checking in to locations. No restaurant reviews, no recommendations, no city guides — just the ability to announce “I am here.” The check-in was compelling enough to attract millions of users, and the data on which secondary features users requested most urgently (tips, friend activity) became the post-MVP roadmap. The canonical “one feature, retention-first” template.
The team killed the bloated Burbn app and shipped a single-feature replacement: post a square photo with a filter. Filters and the share-flow were the entire product. The single-feature retention signal funded the build-out of comments, search, and the rest of the product.
Superhuman
Founder Rahul Vohra invented the “Product/Market Fit Engine” by gating the app behind one core promise — the fastest email experience — and using the percentage of users who said they would be “very disappointed” without it as the retention proxy that drove the entire roadmap. The single-feature focus is “speed at one task” rather than a single capability.
Dropbox
Drew Houston shipped a single feature — a folder on your desktop that synced — before any sharing, collaboration, or storage features. The retention signal on that one feature was strong enough to fund the rest of the product and the demand-validation video that preceded it.
Further reading
Got something to add? Share with the community.