MVP Feature Prioritization: What to Build First (and What to Cut)

MVP feature prioritization is not the art of putting 40 ideas in the correct order. It is the discipline of finding the smallest complete product that can deliver value and teach you whether the business deserves another round of building.

That distinction changes the work. A ranked backlog can still produce a broken MVP: signup without a useful result, a dashboard without data, or an impressive model with no way for a customer to act on it. Your first release needs one thin path from problem to outcome. Everything outside that path is a candidate to cut, fake, buy, or deliver manually.

This guide gives you a practical sequence for making that decision. It covers the familiar frameworks—MoSCoW, RICE, Kano, and value versus effort—but does not pretend a formula can rescue a vague product strategy.

Start with the release hypothesis, not the feature list

Before collecting or scoring features, finish this sentence:

We believe [specific user] will use [smallest complete workflow] to achieve [observable outcome], which will show us [business assumption] is true.

A scheduling product for independent physical therapists might write:

We believe solo physical therapists will send a booking link, have a patient select an available slot, and receive a confirmed appointment without a phone call. If at least a few therapists repeat that workflow with real patients, we will have evidence that self-serve scheduling removes enough administrative work to matter.

This is not a metric target disguised as certainty. It is a statement of what the release exists to learn.

Now every feature has a job. It must either:

1. Help the target user complete that workflow.
2. Make the workflow trustworthy enough to use.
3. Produce the evidence needed to evaluate the assumption.

If it does none of those, it does not belong in the MVP.

This step should follow real problem validation, not replace it. If you have not yet established that buyers care about the problem, start with Validate Before You Build. Feature prioritization is what happens after you have earned the right to build.

Map one end-to-end vertical slice

An MVP must be small, but it cannot be a disconnected layer of a future product. A backend with no usable path to value is not an MVP. Neither is a beautiful interface that depends on operations you cannot actually fulfill.

Intercom describes this with the “cupcake” metaphor: ship a small but complete experience instead of delivering the separate layers of a wedding cake one at a time. Each iteration should produce value that a customer can use and that the business can learn from (Intercom).

Map the journey from left to right:

Step	Question	Scheduling example
Entry	How does the user begin?	Therapist creates an account
Setup	What minimum information is required?	Sets working hours and appointment length
Core action	What does the user do?	Sends a booking link
Counterparty action	What must another person do?	Patient selects a slot
Outcome	What value is delivered?	Appointment is confirmed
Evidence	What will tell us it worked?	Therapist sends another link or keeps using the calendar

Then list the capabilities beneath each step. The first pass might include account creation, availability settings, public booking page, confirmation, calendar view, reminders, payments, analytics, branding, rescheduling, cancellation rules, team accounts, and integrations.

Do not score that list yet. First draw a horizontal line that leaves one usable path above it:

• Account creation
• Basic availability
• Shareable booking link
• Slot selection
• Confirmation
• Simple appointment list

That is a coherent vertical slice. Custom branding may be valuable, but removing it does not break the result. Team permissions may matter later, but a solo therapist does not need them. Automated reminders could improve attendance, but the founder can send them manually during the first test.

The vertical-slice test catches a failure that scoring frameworks miss: individually sensible features can still fail to form a product.

Classify every feature before you rank it

Use four categories that reflect early-stage reality.

1. Core value

A core-value feature is required for the target user to reach the promised outcome. Remove it and the end-to-end journey breaks.

For the scheduling example, availability, a booking page, slot selection, and confirmation are core value. A theme editor is not.

The test is strict:

If this disappears, can the target user still get the outcome we promised?

If the answer is yes, it is not core.

2. Trust gate

Some capabilities do not create the headline value, but users will not responsibly attempt the workflow without them. These can include security, privacy, consent, payment handling, accessibility, data accuracy, backup, moderation, or regulatory requirements.

Trust gates depend on the product and the stakes. A consumer prototype used by five invited testers has different requirements from software storing health information or moving money. “It is only an MVP” does not excuse negligent handling of sensitive data.

The minimum should be determined by the real risk and applicable obligations—not by copying enterprise controls into every product. When the stakes are material, get qualified legal, security, or compliance advice rather than treating a prioritization article as a checklist.

Ask:

• What could materially harm a user if this fails?
• What would prevent a reasonable person from trying the product?
• What must be true before we accept data or money?
• Can a proven third-party service handle this more safely than our own code?

3. Manual substitute

A manual substitute delivers the result without automating the operation. Early products should use this category aggressively.

Examples:

• Founder approves new accounts instead of building automated risk checks.
• Spreadsheet generates a weekly report instead of a reporting engine.
• Stripe Payment Links handle checkout instead of a custom billing system.
• Founder performs data cleanup behind the scenes instead of building an import mapper.
• A personal onboarding call replaces an in-product tutorial.

Manual work is appropriate when it preserves the user outcome and does not avoid the central risk you need to test. If your product claims to detect fraud in real time, manually reviewing every transaction does not validate the technical promise. If the promise is “receive an accurate weekly cash summary,” manual categorization may be a perfectly good way to test whether founders value the output.

Write the manual process down. A hidden pile of founder heroics becomes dangerous when nobody knows what must happen for the product to work.

4. Later

“Later” contains useful ideas that do not belong in the release. This is not a polite synonym for “probably build next.” It is a parking lot that earns no priority until evidence changes.

For each later item, record the trigger that could bring it back:

Deferred feature	Evidence required for reconsideration
Automated reminders	Missed appointments repeatedly block continued use
Team permissions	Multiple paying practices need more than one staff account
Calendar integration	Manual double-entry becomes a repeated reason for churn
Custom branding	Buyers demonstrate that patient-facing trust depends on it

This turns “not now” into an evidence rule instead of a recurring argument.

The best framework depends on what you know

Prioritization frameworks answer different questions. Treating them as interchangeable is how teams create confident-looking nonsense.

Framework	Best question	Use it when	Main failure mode
User-story mapping	Does the release form a complete journey?	You are defining the first usable version	A map can still contain too much unless you draw a hard release line
MoSCoW	What must ship now, and what explicitly will not?	A small team needs a fast scope decision	Founders label every emotionally important idea “Must”
Value vs. effort	Which obvious choices create more learning or value for less work?	Data is thin and you need a lightweight comparison	“Easy” work wins even when it does not test the important risk
RICE	Which opportunity has the strongest evidence-adjusted return on effort?	You have credible reach, impact, confidence, and effort inputs	Guesses become precise-looking scores
Kano	Which capabilities are expected, performance-driving, delightful, indifferent, or harmful?	You can collect structured customer feedback	Founder opinion is substituted for customer reaction

For most pre-launch founders, the sequence is:

1. Story map the core journey.
2. Classify core, trust, manual, and later.
3. Use MoSCoW to draw the release boundary.
4. Use value versus effort for simple tradeoffs.
5. Use RICE or Kano only when you have the evidence they require.

How to use MoSCoW without making everything a must-have

MoSCoW puts requirements into four groups:

• Must have: Without it, the release cannot deliver its core outcome or operate responsibly.
• Should have: Important, but the workflow still works without it.
• Could have: Helpful improvement with limited consequence if deferred.
• Won’t have this time: Explicitly outside the release.

The method is useful because it forces a release conversation. Its weakness is language: founders hear “important” and translate it into “Must.”

Use three tests for a Must:

1. Outcome test: Does removing it break the promised user outcome?
2. Trust test: Does removing it make the product unsafe, irresponsible, or unusable for the target user?
3. Learning test: Does removing it prevent the release from testing the riskiest assumption?

A feature must pass at least one test with a concrete explanation. “Investors expect it,” “our competitor has it,” and “we will need it eventually” do not qualify.

If the Must list still exceeds what you can ship, the problem is not prioritization. Your release hypothesis contains too many users, jobs, or outcomes. Narrow it and run the test again.

How to use RICE without false precision

RICE was developed at Intercom to compare product ideas using four factors:

• Reach: How many people will encounter the change in a defined period?
• Impact: How much will it affect the chosen outcome per person?
• Confidence: How strong is the evidence behind your reach and impact estimates?
• Effort: How much total team time will the work require?

The formula is:

RICE score = (Reach × Impact × Confidence) ÷ Effort

Intercom’s original explanation uses a defined time period for reach, a fixed scale for impact, percentages for confidence, and person-months for total product, design, and engineering effort (Intercom).

RICE is valuable because confidence can penalize exciting ideas with weak support. But a pre-launch startup often has no real reach data and little basis for estimating impact. Entering 500 users, “massive” impact, 80% confidence, and two weeks of effort does not create evidence. It hides assumptions inside arithmetic.

Use RICE pre-launch only if you:

• Define what each input means before scoring.
• Link every estimate to interviews, waitlist behavior, prototype tests, comparable usage, or engineering discovery.
• Lower confidence when the evidence is weak.
• Include design, testing, migration, operations, and maintenance—not only coding—in effort.
• Treat the ranking as a conversation starter, not an automatic decision.

Never use RICE to pull a disconnected feature into the MVP. The vertical slice and trust gates come first.

How to use Kano when customer expectations matter

The Kano model classifies requirements by how their presence or absence affects satisfaction. The commonly used categories are:

• Must-be: Expected basics; their absence creates dissatisfaction, while their presence earns little praise.
• Performance: More or better performance tends to increase satisfaction.
• Attractive: Unexpected capabilities that can delight but are not missed when absent.
• Indifferent: Capabilities that do not materially change satisfaction.
• Reverse: Capabilities some users prefer not to have.

Kano is based on customer responses, commonly gathered through paired functional and dysfunctional questions—how someone feels if a capability exists and how they feel if it does not. It is not a founder sorting features into “boring” and “cool.” Intercom’s overview explains the five categories and the questionnaire basis of the model (Intercom).

For an MVP, Kano can help you avoid two mistakes:

1. Missing an expected basic. The core workflow technically works, but users will not trust or understand it.
2. Overbuilding delight. You spend the release on novelty while the basic outcome remains unreliable.

Use it after you have access to representative users. Before that, mark your classifications as hypotheses and resist building a “delighter” merely because the team likes it.

Use value versus effort when the data is thin

A value-versus-effort matrix is intentionally simple. Put each candidate into one of four quadrants:

	Lower effort	Higher effort
Higher value or learning	Do or investigate first	Strategic bet; reduce scope before committing
Lower value or learning	Fill-in work only if capacity is stranded	Cut

For an MVP, replace vague “value” with one of two things:

• Contribution to the core user outcome
• Reduction of uncertainty around the riskiest assumption

That prevents easy but irrelevant work from floating to the top. A one-day dark mode may be easier than a reliable import flow, but it does not matter if users cannot get their data into the product.

Effort should include the entire cost of ownership:

• Product and design decisions
• Implementation
• Testing and edge cases
• Infrastructure and vendor costs
• Support and manual operations
• Security and compliance review where needed
• Ongoing maintenance

A feature that takes two days to code but creates a permanent support burden is not a two-day feature.

Add a technical-founder filter

Technical founders have a specific prioritization problem: the work that feels intellectually responsible can be commercially premature.

Run every surviving item through these questions.

Is this the risk we need to de-risk now?

Separate business risk, usability risk, and technical risk.

• Business risk: Will anyone care enough to use or pay?
• Usability risk: Can the target user reach the value without help?
• Technical risk: Can the differentiating mechanism work at the required level?

Build against the riskiest unproven assumption, not the most interesting engineering problem.

Is the decision reversible?

Use shortcuts for reversible decisions. Spend more care on choices that are expensive to unwind.

Often reversible early:

• Internal admin interface
• Manual onboarding
• Report formatting
• Small-scale data cleanup
• Vendor used for a commodity capability

Potentially expensive to unwind:

• Tenant and permission boundaries
• Handling of regulated or sensitive data
• Core data ownership and deletion model
• Money movement and ledger logic
• Public API contracts
• A technical approach that determines whether the claimed result is possible

This is not a license to build “scale architecture.” It is a reason to identify the few foundations where a shortcut could invalidate the test or create unacceptable risk.

Can we buy or borrow the commodity layer?

Authentication, billing, email delivery, analytics, file storage, search, and admin tooling may be essential to the workflow without being your product’s edge. Use mature services when they reduce risk and preserve learning.

The goal is not zero dependencies. The goal is to spend custom engineering on the part customers are choosing you for.

Can we observe the result?

Every core capability should produce an observable event tied to the release hypothesis. “Feature shipped” is not an outcome.

Examples:

• Booking link sent
• Patient completed booking
• Appointment happened
• Therapist created another link

Choose the smallest set of events that tells you whether the workflow works and repeats. Do not build an analytics suite to measure an MVP.

A worked example: prioritizing a B2B reporting MVP

Suppose you are building a product that sends agency owners a weekly client-profitability report by combining time tracking and invoice data.

The initial list contains:

• Connect time-tracking account
• Connect accounting account
• Import historical data
• Match projects and clients
• Calculate revenue, labor cost, and gross profit
• Weekly email report
• Interactive dashboard
• Custom report builder
• Team permissions
• Benchmarking
• Slack alerts
• PDF export
• AI-written recommendations
• Data-quality warnings
• Billing

Step 1: Write the hypothesis

We believe owners of small agencies will connect their operating data and review a weekly client-profitability summary because their current spreadsheets do not surface unprofitable work quickly enough. Repeated weekly opens and follow-up conversations will show whether the summary changes attention or action.

Step 2: Map the vertical slice

The owner must connect or provide data, the system must match it well enough to calculate a result, and the owner must receive and understand the report.

Step 3: Classify the list

Feature	Classification	MVP decision
Time and invoice data	Core value	Accept CSV uploads before building two integrations
Project-client matching	Core value	Founder reviews uncertain matches manually
Profitability calculation	Core value / technical risk	Build and test carefully
Weekly report	Core value	Email a fixed report
Data-quality warnings	Trust gate	Show missing or ambiguous inputs
Interactive dashboard	Later	Report delivers the initial outcome
Custom report builder	Later	No evidence users need flexibility yet
Team permissions	Later	Founder-only test
Benchmarking	Later	Requires credible comparison data
Slack alerts	Later	Email is enough to test attention
PDF export	Manual substitute	Founder exports on request
AI recommendations	Later	First prove the numbers are useful
Billing	Manual substitute	Invoice pilot customers or use a payment link

Step 4: Check the learning integrity

Could the founder manually calculate the entire report? Yes—but then the product would not test whether the data pipeline and profitability logic can produce a reliable result. Manual data cleanup may be fine; manually inventing the core calculation is not.

The resulting MVP is smaller than the original vision, but it is not a toy. A customer can provide data, receive a trustworthy report, and decide whether to keep using it.

Run a 90-minute prioritization session

You do not need a two-day offsite. For a small founding team, use this agenda.

Before the session

Bring:

• Evidence from problem interviews or validation tests
• One release-hypothesis draft
• One list of candidate features with duplicates removed
• A rough engineering view of the largest uncertainties
• The person who can make the final scope decision

Agenda

Time	Work	Output
0–15 min	Agree on user, outcome, and riskiest assumption	One release hypothesis
15–35 min	Map the end-to-end journey	One vertical slice
35–55 min	Classify core, trust, manual, and later	A cut feature list
55–70 min	Apply MoSCoW to remaining items	Release boundary
70–80 min	Check technical risk and total effort	Risks and discovery tasks
80–90 min	Write scope lock and measurement plan	Final MVP brief

End with five artifacts:

1. Release hypothesis
2. Journey map
3. In-scope list
4. Not-now list with evidence triggers
5. Events or observations that will determine what happens next

If the session ends with a score spreadsheet but no explicit exclusions, you have not prioritized.

Lock scope without ignoring new evidence

A locked scope should be stable, not stubborn. The point is to stop casual additions while preserving the ability to respond to reality.

Use a re-entry rule. A proposed feature can enter the release only if the proposer states:

1. What new evidence appeared?
2. Which release assumption changed?
3. Why does the current vertical slice fail without this feature?
4. What work leaves the release to make room?

That fourth question matters. Capacity does not expand because a new idea is good.

Review scope at a fixed cadence—weekly for a very short build, or every two weeks for a longer one. Urgent safety or correctness issues can bypass the cadence. Preferences and speculative improvements cannot.

Intercom’s product team argues for building in small steps because smaller changes are easier to validate, review, and adjust, while large bundles make it harder to identify what worked (Intercom). Scope discipline preserves that learning advantage.

Measure behavior, then prioritize version two

After launch, replace assumptions with observed behavior.

Use an evidence ladder:

1. Observed failure in the core journey — strongest reason to fix now.
2. Repeated behavior showing unmet need — users create the same workaround or stop at the same point.
3. Repeated request from target users with context — useful, especially when paired with behavior.
4. Single request — a clue, not a roadmap.
5. Advisor or investor suggestion — perspective, not user evidence.
6. Competitor feature — proof that someone built it, not that your user needs it.
7. Founder preference — valid only when labeled honestly and weighed against the release goal.

Do not reward the loudest requester. Look for patterns tied to the target user and the outcome you are trying to create.

Version two should begin with the same questions as version one: what changed, what is now the riskiest assumption, and what is the smallest complete step that can teach us something useful?

The MVP prioritization worksheet

Copy this into a document and fill it out before development begins.

Release hypothesis

We believe [specific user] will use [smallest complete workflow]
to achieve [observable outcome], which will show us [assumption] is true.

Feature filter

For each feature, answer:

Feature:
User and journey step:
Outcome it enables:
Evidence supporting it:
Classification: core / trust / manual / later
What breaks if removed:
Total effort and ongoing burden:
Decision: build / buy / manual / defer / delete
Evidence required to reconsider:

Scope lock

Release date or window:
In-scope vertical slice:
Explicitly not in scope:
Technical risks to de-risk:
Trust gates that must pass:
Manual operations required:
Events or observations to collect:
Scope review cadence:
Final decision-maker:

Then connect the scope to an actual shipping plan. Our 90-day MVP guide turns the release boundary into a week-by-week build, test, and launch sequence. If you need to fill a commodity part of the stack without hiring, compare the options in our no-code MVP tools guide.

The final rule

Build a feature now only when removing it would break the core outcome, violate a real trust requirement, or prevent the MVP from testing its riskiest assumption.

Everything else should be bought, borrowed, performed manually, deferred with an evidence trigger, or deleted.

That is what makes an MVP minimum. The complete journey is what makes it viable.

Sources

• Intercom — RICE prioritization framework for product managers
• Intercom — What is the Kano model?
• Intercom — Start with a cupcake
• Intercom — Building in small steps to deliver maximum customer value
• Codivox — How to prioritize features for your MVP
• Rocket.new — MVP feature prioritization for non-technical founders
• 6sense — How to prioritize features for your MVP