The Smallest Useful Feature: A Decision Framework

What you actually need to know

• Every feature a founder describes is a maximal version. The developer's job, and the founder's job, is to find the minimal version that still earns the user's trust.
• The smallest useful feature is not the same as the worst acceptable version. It is the version that does the job cleanly without extras.
• Features rarely ship too small. They almost always ship too large and too late.
• The decision of where to draw the line on each feature is the most important design decision on an MVP.
• Naming that line in writing before development starts is the cheapest way to prevent scope creep.

The core argument

Every founder I have worked with arrives at the first planning session with features that are described in their maximal form. A user profile does not mean a name and an email. It means a profile photo, a bio, custom links, a public page, privacy settings, and a notification preference center. A search feature does not mean a text box that filters results. It means faceted search, saved searches, recent history, and fuzzy matching.

These are not bad descriptions. They are accurate descriptions of what the feature looks like when it is fully built. The problem is that "fully built" is not the goal on an MVP. The goal is "useful enough that a real user would choose to use it." Those are different targets, and the gap between them is the waste that kills timelines and budgets.

The framework I use is a single question applied to every feature: what is the one thing this feature needs to do for the user to feel like it worked? Everything else is either a convenience layer on top of that one thing, or a solution to a problem the user does not yet have. The conveniences become version two. The non-problems get dropped entirely.

Finding the line takes discipline. Founders resist because the extras feel necessary. Developers sometimes resist because building the extras is interesting work. The brief is the tool that holds the line. When the line is written down before the build starts, every addition is visible as an addition rather than as a natural extension.

The framework in practice

Step one: name the job

Write one sentence describing what the user needs to accomplish. Not the feature. The job. "The user needs to submit a request and know it was received." Not "the user needs a request form with status tracking, history, and document attachments."

Step two: find the minimum that completes the job

List the absolute minimum set of components that allows the user to complete the sentence you wrote in step one. For the request submission example: a form, a submit button, a confirmation message. That is it.

Step three: test it against the trust bar

Ask: if a real user submitted a request and saw a confirmation message, would they trust that the system worked? If yes, that is your version one. If not, what one element would move the answer to yes? Add only that element.

Step four: write down everything that was deferred

This is the step most teams skip. Everything that was considered and deferred in the previous steps gets written into a "version two" list, with a note on what signal from users would justify building it. This list prevents the deferred features from creeping back in during the build and gives the team a data driven reason to build them later.

How long does it take

The planning time above is not optional. Teams that skip it spend it later, in the form of rework, in the middle of a build where changes are expensive.

What to look for in a well-scoped feature

• A one sentence job description that a non technical person would agree with.
• A build list with fewer than five components for a simple feature, fewer than ten for a complex one.
• A written version two list that captures everything deferred.
• A trust test that was answered honestly rather than optimistically.
• No "nice to have" items in version one. Nice to have is version two's first priority.

Expert opinion

The founders who move fastest are the ones who have made peace with shipping less than they planned. Not because less is better, but because the feedback from a smaller thing in the hands of real users is worth more than the completion of a larger thing that has not yet been tested. The version two you build from real feedback is always better than the version two you planned in advance.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

On a marketplace MVP I worked on, the founder's original feature list for the seller profile included a photo gallery, a rating display with written reviews, a service menu with pricing tiers, a response time badge, and a "contact" button. All reasonable. The total build estimate for that feature set was three weeks.

We applied the framework. The job: a buyer needs to see who the seller is and be able to contact them. The minimum: a name, a short bio, a profile photo, and a contact button. Build time: two days. We shipped the two day version. Real buyers used it. The feedback was that the contact button opened a messaging thread with no subject line context, which made follow up difficult. We fixed that in day three. The rating display did not come up in any feedback for the first month. We deferred it correctly.

For the broader scoping conversation, 7 MVP mistakes that destroy startups before they launch covers why oversized feature lists are the number one cause of missed launches. The cut decisions also connect directly to what to cut from your MVP when the budget drops, which addresses the same logic under budget pressure.

Common mistakes

1. Confusing the feature description with the job description. One describes a solution. The other describes a need. Start with the need.
2. Adding the convenience layer in version one because it "only takes an hour." Hours accumulate.
3. Skipping the version two list. Deferred features re-enter the build if they are not captured somewhere.
4. Applying the trust test optimistically. Ask it honestly. The answer should come from user behavior, not from founder assumption.
5. Finding the smallest useful version in your head rather than writing it down. The written version survives meetings. The mental version does not.
6. Treating the framework as a one time exercise. Apply it to every feature, including ones added after the build starts.
7. Letting the developer expand the scope during implementation without a conversation. Every addition should be a decision, not a reflex.

A 7 day plan

1. Day one. List every feature in the build. For each one, write a one sentence job description.
2. Day two. Apply the minimum test to each job description. List the components. Test against the trust bar. Write the version two list.
3. Day three. Review the resulting version one list with your developer. Add only what the developer identifies as technically necessary to prevent breakage. Nothing else.
4. Day four to six. Build using the scoped list. Any developer proposal that extends a feature goes through the job description test before it enters the build.
5. Day seven. Review what was built against the version one list. Anything that grew beyond the list gets noted. Understand why it grew. Use that to improve the scoping process for the next sprint.

For more on the build cadence that makes this discipline stick, agile for early stage startups covers the weekly rhythm that keeps scope honest over time. For the specific case of what to do when budget forces the decision, the stages of an MVP build covers the mental model that makes cutting less painful.