How to launch a product: from idea to MVP / Decide what to build
How to prioritize features for a first version
When the feature list is long and everyone involved wants their idea in version one, prioritization gets political. The fix is a shared rule that ranks features by how much they serve the one thing your MVP tests, not by who argues hardest. Make the rule explicit and the arguments get easier.
Published July 27, 2026. Editorial.
Key takeaways
- Prioritize by contribution to the core test, not by who is loudest in the meeting.
- Sort features into must-have, later, and never, and be honest that most are later.
- A must-have feature is one where the core action fails without it. Everything else can wait.
- Write the rule down so prioritization is a shared method, not a contest of who argues best.
Once you have a scope, the feature list still needs an order, and that is where teams stop making progress. Everyone has a feature they are sure is essential. Without a shared rule, the loudest or most senior voice wins, which is a bad way to build a product. A clear prioritization method turns a political argument into a repeatable decision.
Rank against the core test, not against taste
The rule is simple: a feature's priority is how much it contributes to testing your riskiest assumption. Your MVP exists to answer one question, as covered in how to scope an MVP. A feature that is required for that test is a must-have. A feature that would be nice but is not required is later. A feature that serves a different question entirely is not for this product yet.
This reframes every debate. Instead of "is this feature good," which everyone answers yes to, the question becomes "does the core test work without it." That question has a real answer, and it is usually yes, which means the feature waits.
Use three groups, and be honest
Sort every feature into three groups. Must-have: the core action fails without it. Later: valuable, but the core action works without it, so it waits for a future version. Never, or not yet: it serves a different product or a user you are not building for.
The honesty test is the size of your must-have group. If most of your features are going into must-have, you are not prioritizing, you are rationalizing. A real MVP has a small must-have list and a long later list. Make the groups uneven. If everything is essential, nothing is, and your first version will take too long to release.
Watch for the common mistakes
A few patterns quietly make the must-have group too large.
The "it is easy to add" mistake: a feature is small, so it feels free. It is not free. Every feature adds testing, unusual cases, and more parts to support, and small features add up to a slow launch. Small is not a reason to include, it is a reason it can safely wait.
The "we will need it eventually" mistake: probably true, and still not now. Eventually is exactly what the later list is for. Building for a future you have not validated is how MVPs turn into full products.
The "a big customer asked" mistake: one strong request is not proof of broad demand. Note it, put it on the later list, and see if the pattern repeats once real users arrive. The evidence you want comes from getting your first users and feedback, not from a single customer.
Bring the right people, and one decider
Good prioritization needs the people who understand users and the people who understand what is hard to build, in the same conversation. Engineers often reshape a feature into something far cheaper that gets most of the value, which changes its priority. This is part of why a strong product manager matters so much, a point we make in five ways to hire the right product manager.
But a group cannot prioritize by consensus, or everything becomes a must-have to avoid conflict. Someone has to make the final decision. On an early product that is usually the founder. Gather the input, apply the rule, then decide. As we put it in the founder's job is to remove ambiguity, making the hard decision so the team can move is the job.
Keep re-prioritizing
Priority is not set once. Every launch and every round of real feedback changes what matters, so revisit the list as you learn. A feature that was later can become a must-have once users show you it is blocking them, and a must-have you were sure of can turn out not to matter. Take the ranked list back to the main guide and let real usage keep changing it.
Common questions
How should I prioritize features for an MVP?
Rank each feature by how much it contributes to testing your riskiest assumption. If the core action fails without it, it is a must-have. If the core action works without it, it is later. Use three groups, must-have, later, and never, and be honest that most features are later.
What makes a feature a must-have versus a nice-to-have?
A must-have is a feature where the core action of your product fails without it. A nice-to-have is valuable but the core action works without it, so it waits. If your must-have list is long, you are rationalizing, not prioritizing. Real MVPs have a short must-have list.
Who should make the final decision on feature priority?
Gather input from the people who understand users and the people who understand what is hard to build, then let one person decide. On an early product that is usually the founder. Consensus prioritization turns everything into a must-have, so someone has to make the decision.
What is the difference between scoping and prioritizing an MVP?
Scoping defines the single core action an MVP needs to deliver and the boundary of what is in the first version at all. Prioritizing takes the list of possible features inside or near that scope and ranks them into must-have, later, and never, based on how much each one contributes to testing the riskiest assumption. Scoping sets the boundary, prioritizing orders what sits near it.
How do I prioritize features when I have limited time or budget?
Rank every feature by whether the core action fails without it, and put everything else on a later list, since limited time makes that discipline matter more, not less. Watch for features that feel free because they are small: every addition still adds testing and more parts to support, and small additions add up to a slower launch than the budget allows.
Is it safe to launch with a short must-have list?
Yes, a short must-have list is a sign of good prioritization, not a risk. A real MVP has a small must-have group and a long later list, because most features are valuable but not required for the core action to work. Launching with only what is truly required lets you test the riskiest assumption faster and with less wasted work.
How do I stop stakeholders from arguing that every feature is essential?
Replace the vague question of whether a feature is good, which everyone answers yes to, with the specific question of whether the core action fails without it. That question has a real, checkable answer. Writing the rule down ahead of time also helps, since prioritization becomes a shared method applied to every feature rather than a contest of who argues best in the meeting.
What is the risk of getting feature prioritization wrong on an MVP?
Getting prioritization wrong usually means too many features go into the must-have group, which turns a focused MVP into a slow, expensive build that tests nothing clearly. When a weak response comes back after launch, a feature set that is too large makes it impossible to tell which feature caused it, so the whole experiment produces weaker evidence than a tightly prioritized one would.
Related reading
Five ways to hire the right product manager
The right product manager changes the direction of a team. The wrong one quietly slows everything down.
You cannot measure engineers by how much they produce
Lines of code, tickets closed, and hours logged all measure activity rather than progress. Here is how we think about engineering output without numbers that only look good.
More in Decide what to build
How to validate a product idea before you build
The cheapest MVP is the one you never had to build. Before you commit engineers, you can test most of your assumptions with conversations, a landing page, a clickable prototype, or a service you run by hand without the user seeing it. Validation is how you find out the idea is wrong while it is still cheap to be wrong.
How to scope an MVP
Scope is the most important decision in your launch, and it is where most MVPs go wrong. The fix is to scope around one question, not your whole roadmap. Define the single core action that tests your riskiest assumption, build only what is needed for it, and let everything else wait.