MVP feature prioritization: decide what to build, later, or cut

You have a list of features. It came from customer calls, a competitor teardown, an investor's question, and your own notes. It is longer than the first release can hold, and everyone who added to it can defend their item.

MVP feature prioritization is the work of turning that list into a decision: which features the first release needs, which ones a person can cover by hand for now, which ones wait for evidence, and which ones leave the list. This article shows one way to make that decision and write it down, using a single matrix with four outcomes: build now, manual workaround, later, or cut.

It does not rank prioritization methods, and it does not cover how to test the scope once you have chosen it. It does end with a filled-in matrix for one example product, so you can copy the structure and fill it with your own features.

Set the decision frame

How to prioritize features in an MVP depends less on the method than on what the features are compared against. Before you compare anything, write down four things about the product. Each fits in one sentence. Every decision in the matrix refers back to them, so if two people on the team would write them differently, settle that first.

1. Target user. One role, described by the job they do. "The finance lead at a company with one or two people in finance" is usable. "SMBs" is not.
2. Problem. What that user does today and what goes wrong. If you cannot say what goes wrong, you have a solution in search of a problem, and the matrix will show it later.
3. Core outcome. The one result the product must let the user reach, stated as something the user would recognize as done.
4. Smallest end-to-end workflow. The shortest path from the user's first step to the core outcome. This is the MVP scope in its narrowest form. Everything else in the release exists to support that path.

Two more inputs shape the frame without being part of it. The business goal (what the first release has to prove to you, your co-founders, or your investors) tells you which evidence matters most. The budget and the team, in whatever form you have them, put a ceiling on the effort column. Neither one adds a feature. They only narrow the list.

Here is the frame for the example product used through the rest of this article. It is an illustration, not a client project, and the decisions below apply to this product only.

• Target user: the finance lead at a company with one or two people in finance.
• Problem: supplier invoices arrive by email, approvals happen in reply threads, and at month-end nobody can say which invoices were approved, by whom, or when.
• Core outcome: an invoice moves from "received" to "approved" or "rejected," with a record of who decided.
• Smallest workflow: an invoice gets into the tool; the finance lead assigns an approver; the approver decides and leaves a comment; the status shows up in a list the finance lead can read.

The frame is deliberately narrow. Anything that does not sit on that path needs a written reason to be in the release, and the matrix is where the reason goes.

Build the feature list from user journeys

The feature list should come from what users do. Write two or three user journeys against the frame and pull candidate features from the steps where the journey stalls. Beside each candidate, write the assumption it rests on and the dependency it introduces. Those two notes decide most of the matrix later.

For the example product, three journeys cover the frame.

Journey 1: an invoice arrives. The finance lead gets a PDF by email, checks who should approve it, and asks that person. Candidate MVP features: forward-to-inbox ingestion, manual PDF upload, and automatic extraction of vendor, amount, and due date.

• Forward-to-inbox rests on the assumption that finance leads will change where their invoices go. It depends on inbound email parsing and attachment handling.
• Automatic extraction rests on the assumption that typing three fields by hand is too slow to tolerate. It depends on an OCR service and on a review step for its mistakes.

Journey 2: the approver decides. A department head gets a request, looks at the invoice, approves or rejects it, and says why. Candidates: email notification, Slack notification, approve or reject with a comment, delegation to a colleague, and multi-level approval chains.

• Slack notification assumes approvers work in Slack. It depends on building and maintaining a Slack app.
• Multi-level chains assume the target user needs two approvers per invoice. They depend on a rules engine and an escalation path.

Journey 3: month-end. The finance lead needs to know what is still pending and what was decided. Candidates: a status list with filters, CSV export, sync to accounting software, and a dashboard of approval time by department.

• Accounting sync assumes the finance lead re-enters approved invoices in another tool today. It depends on OAuth, field mapping for each accounting product, and error handling.
• The dashboard assumes someone will act on approval-time data. It depends on nothing, and at this point no user has asked for it.

That is a dozen candidates from three short journeys, which is a normal size for an MVP feature list. The matrix shrinks it. The journeys are also where a story mapping session pays off if the team prefers a wall of sticky notes to a document; the output is the same list of steps and candidates.

Separating a feature from a future enhancement

A feature belongs to this MVP when the smallest workflow does not complete without it, or when its absence would make the target user abandon the workflow at a step you have observed. A future enhancement makes an existing step faster, wider, or nicer: more channels, more roles, more automation, more formats. Enhancements stay on the list with their assumption beside them, but labeled, so nobody mistakes "we thought of it" for "we decided to build it."

A useful first screen for many rows is: assuming the rest of the smallest workflow exists, does adding this feature materially move the target user closer to the core outcome? Approve or reject with a comment passes. Slack notification does not; it is an enhancement of "the approver is told." Automatic extraction does not; it is an enhancement of "the invoice data is in the tool." Accounting sync does not; it is an enhancement of "the status is visible."

Free kit. If your journeys are still guesses, grab the free user research repository kit, a reusable Notion kit with research questionnaires, interview scripts, and feature-mapping tools, so the evidence column below has something to cite.

The MVP feature prioritization matrix: build now, manual workaround, later, or cut

The MVP feature prioritization matrix has five columns per feature. Four hold evidence; the fifth holds the decision. No column is a number, and there is no formula that turns the four into the fifth. The decision is an argument the team can read back later; a score cannot be.

• User/problem evidence. What you have seen or heard that says this feature solves the frame's problem for the frame's user: interview notes, support tickets, behavior observed in a prototype, or "none yet." "None yet" is a valid entry and an important one.
• Impact on the core workflow. Does the smallest workflow complete without this feature? Three answers: blocks it, slows it, or no effect.
• Implementation and dependency effort. Build effort in the team's own terms, plus what the feature brings with it: a third-party service, an integration, a data-model change, a review process.
• Risk and unknowns. What you would have to be wrong about for this to be a bad call, and what you do not know yet, such as whether a vendor's API does what its documentation says.
• Decision. Build now, manual workaround, later, or cut. Manual-workaround and later rows need a review trigger; cut rows need a recorded reason and reopen only when new evidence changes the frame.

Filled in for the example product:

Six rows are enough to show the shape. A real list has more, and most of the extra rows go to later or cut faster than these did, because their evidence column is empty.

What each outcome means

Build now. The smallest workflow does not complete without it, and you have evidence (interview notes, tickets, observed behavior) that the user needs it in this form. If the evidence column reads "none yet," the feature is not a build-now candidate, however obvious it feels.

Manual workaround. The need is real, but a person can meet it during the MVP without code. Someone on the team does the step by hand, a spreadsheet stands in for a screen, or an email replaces a notification. This is the concierge pattern: the user knows the step is manual. It is a decision in its own right, and it produces the thing the evidence column is usually short of: observed behavior. How often the step happens, how long it takes, and what goes wrong all go into the row when the trigger fires.

Later. The need is real and the evidence may be good, but the workflow completes without the feature today. A later label only means something with a review trigger attached: an event that reopens the row. A date is not a trigger.

Cut. The evidence is weak or absent, or the request is a stakeholder preference rather than a user problem. Cut rows stay in the record with the reason, so the same request does not come back with the same argument.

This is the distinction people mean by must-have vs. nice-to-have features in an MVP, with two changes. Nice-to-have splits into manual workaround and later, so a real need is not discarded just because it is not code yet. And cut gets a written reason.

Where the columns come from. The matrix borrows from tools you may already use. The Kano model, which sorts features into must-be, performance, attractive, indifferent, and reverse, is useful for one check: whether a feature the team calls nice-to-have is something the target user assumes is there and would leave over. A feature priority matrix or a value-versus-cost quadrant is the ancestor of the impact and effort columns; the difference here is that the two are never combined into a single number. Story mapping, mentioned above, is a way to run the journey exercise on a wall. None of the three replaces the matrix. They fill its cells.

How to run the decision meeting

The meeting has one output: a scope decision, recorded, in one sitting. It is not a backlog grooming session, and it does not end with a longer list.

Three roles have to be in the room. They are roles, not titles; in a small team one person may hold two.

• The person who owns the decision. Founder or product owner. Breaks ties and signs the record.
• The person who has talked to users. Whoever ran the interviews or reads the support inbox. Fills the evidence column and is allowed to say "we have nothing on this."
• The person who will build it. The technical owner. Fills effort and dependency and names the unknowns.

If a manual workaround is on the table, add whoever will do the manual work. They know what a week of it means.

What changes a decision. Entries in the evidence column: an interview note that describes the problem in the user's words, a support ticket or sales objection tied to a named account, behavior observed in a prototype or in the manual workaround, a hard dependency the technical owner found. What does not change a decision: a competitor has the feature, an advisor likes it, it demos well, or "users will expect it" without a user who said so.

What to record. One row per feature with the five columns and who filled each. For every row, the assumption it rests on in one sentence. For every manual-workaround or later row, the review trigger. For every cut row, the recorded reason. "Two pilot customers ask for multi-level approval" is a trigger. "Q3" is not. Then the date and the names of the people who decided. That record is the MVP feature prioritization framework in practice: the same columns and the same four outcomes, applied again every time the list changes.

Why there is no scoring formula. Weighted scoring looks objective, but a single number hides which column carried the decision, and if the arithmetic is set up wrong, high effort raises the score instead of lowering it. It also moves the argument from evidence to weights. If the team wants a tiebreaker after the discussion, rank the build-now rows by impact on the core workflow, by hand, in order.

Later can mean a later release. Scope can be staged across releases as well as within one. Waffly, an audio product with AI features, is one example from Merge's own work. Its first release was a proof of concept scoped to one capability. The MVP was a separate release that followed. From the case study: "Successfully shipped a Proof of Concept (POC) within a month." Val Wikstrem, CEO at Waffly: "Achieving the delivery of a POC within just one month helped us to fundraise our angel round and begin to work on the complete MVP." That is one product's sequence. It is not a timeline to plan around. The point is that what stayed out of the first release stayed out on purpose, with the next release named.

Worked hard calls

Some features come up in almost every MVP scope discussion. None has a fixed answer; each depends on the frame. Account creation is worked through all five columns for the example product below. The other four are shorter.

Account creation

Evidence. The workflow involves two people in two roles, and the approver has to open a request addressed to them. The interviews show approvals happening between named people, so the need to attribute a decision is observed. What is not evidenced: that customers need to sign up on their own.

Impact. An approver needs some identity to act, or the decision cannot be attributed, and attribution is the core outcome. Self-serve sign-up, team management, and single sign-on have no effect on the workflow for a pilot customer.

Effort and dependency. Magic-link sign-in by email: low. Self-serve workspace creation with invites, roles, and password reset: medium. SSO: high, plus a dependency on each customer's identity provider.

Risk. A pilot customer's IT may block magic links. Unknown until the first customer tries.

Decision. Build now: magic-link sign-in for approvers, one workspace per customer. Manual workaround: the team creates each pilot workspace and adds its users by hand. Later: self-serve sign-up and roles, with the trigger that manual onboarding falls behind the customers waiting for it. Cut for this release: SSO, unless a pilot customer's security policy requires it, in which case the row reopens for that customer.

If the frame were different, say a consumer product where the core outcome is something one person does alone, account creation might be a later row entirely and the first release would work without accounts. The cell contents change with the frame. The columns do not.

Integrations

If the core workflow cannot start without data that lives in another system, the integration is a build-now feature, and its unknowns (API limits, authentication, data quality) are the largest risk in the release. If the workflow can start from a manual upload or a CSV, the integration is a manual workaround or a later row. In the example, the accounting sync is later: it saves the finance lead from re-typing after the approval, which the workflow does not depend on. A bank feed for a reconciliation tool would be the opposite case.

Reporting

A report summarizes a workflow that already runs, so for most first releases it belongs in later or cut. The exception is a product whose core outcome is "the user sees X." Then the report is the workflow, and the question becomes which single view is the report. In the example, the status list is that view, and the dashboard is cut because its only evidence was the investor demo.

Automation

Automation replaces a manual step. If nobody has done the step by hand yet, you do not know its shape: how often it happens, which inputs are messy, where it fails. The manual workaround outcome exists for this reason. In the example, automatic extraction of vendor, amount, and due date from a PDF is the tempting automation. The workaround is to type three fields and time it. If typing takes seconds, the OCR row moves to cut. If it takes a noticeable part of every day and wrong amounts show up in approved invoices, it moves to build now with the evidence attached.

Polish

There are two kinds. Polish that blocks the workflow, such as an approver who cannot find the decision button on a phone, is part of the build-now feature and goes in the same row. Polish that is taste, such as custom branding, dark mode, animations, or empty-state illustrations, goes to later or cut unless the evidence column names a user who left over it. The distinction is easier to hold if the evidence column says "unusable" or "unattractive" instead of "bad UX" for both.

Common traps in MVP feature prioritization

Each trap breaks a specific column. Naming the column is the fastest way to catch the trap in the meeting.

1. Prioritizing by stakeholder preference. A founder's favorite, an investor's ask, an advisor's pattern-match. It breaks the evidence column: the entry reads "X wants it," which is not user evidence. The fix is procedural. The row cannot be marked build now until someone fills the column with something a user did or said.
2. Mistaking a solution for a problem. "We need a chatbot" or "we need OCR" enters the list as a feature with the problem left unstated. It breaks the frame and the evidence column at once, because there is nothing to check the feature against. Rewrite the row as the problem ("approvers do not answer email requests") and let the candidate features follow from it.
3. Planning every edge case up front. Delegation when the approver is on leave, currency conversion, duplicate detection, partial approvals. Each is real. Together they inflate the effort column until a build-now feature looks like a quarter's work. Separate edge cases into their own rows. Build the ones required for safety, security, compliance, accessibility, data integrity, or to prevent a likely core-workflow failure. Give the rest a later decision with a review trigger.
4. Keeping untested assumptions in scope without a label. The feature is marked build now, and the assumption it rests on ("users will set up forwarding") lives in someone's head. It breaks the risk column and the review triggers with it: nothing reopens the decision because nothing was written. Every build-now row gets its assumption written down, even when the entry is "none."

Next step

The decision rests on three things: what the business needs the release to prove, what the people in the room know, and what the target user has been observed to need. The frame holds the first, the meeting holds the second, and the evidence column holds the third. When all three are written down, the four outcomes follow from the rows without much argument.

Once your list carries four labels, two questions remain, and this article answers neither. The first is the order in which the build-now features get built and why. That is a different decision from which features are in, and it is covered in our guide to sequencing what to build first. The second is how to test the assumptions you kept in scope, which is its own topic.

If you would rather work through the matrix with our team, you can talk through your MVP scope with our team. That conversation covers what belongs in release one, what can wait, and what still needs an answer before anyone designs or builds.