As a SaaS Founder, You Have a "No" Problem
Every SaaS product team eventually hits the same wall. The backlog has two hundred items, the roadmap meeting runs over by an hour, and everyone leaves convinced their feature was the one that actually mattered. The problem is…
You suggest something
The CTO suggests something
The client suggests something
The research suggests something
The competitors do a new feature
Every SaaS product team eventually hits the same wall. The backlog has two hundred items, the roadmap meeting runs over by an hour, and everyone leaves convinced their feature was the one that actually mattered. The problem is rarely a shortage of good ideas. It is the absence of a shared, visible way to rank them.
MoSCoW solves that. It was developed in the 1990s for software delivery, and it still holds up because it forces a decision that most teams avoid making explicitly: not everything can be a priority. The name comes from four categories. Must have, Should have, Could have, Won’t have. Applied properly, it turns a subjective argument into a structured conversation with a paper trail.
Here is how each category plays out inside an actual SaaS product.
Must have
These are the features without which the product does not function or cannot be sold. For a subscription-based SaaS platform, that typically includes authentication, a working payment integration, and the core workflow the product is built around. If a project management tool cannot create and assign tasks, it is not a minimum viable product; it is a wireframe. Must-have items are non-negotiable, and they should never exceed roughly half of a team’s delivery capacity in a given cycle. If they do, the category has lost its meaning.
Should have
Important to the product’s value but not fatal if delayed by a release or two. A usage-based analytics dashboard on that same project management tool falls here. Customers get real value from task creation and assignment on day one. The dashboard makes the product better, but its absence at launch will not sink adoption. Should have items are the first candidates to slip when a must-have item runs over schedule, and that tradeoff should be named out loud in planning, not discovered quietly during a sprint retrospective.
Could have
Desirable, low risk, and easy to cut without anyone outside the team noticing. Custom themes, a dark mode toggle, an additional export format. These earn their place when time genuinely allows, and they are the first line item removed the moment a must-have feature turns out to be harder than estimated.
Won’t have, this time
This is the category most product teams skip, and it is the one that does the most work. Explicitly writing down what will not be built this quarter, whether that is a native mobile app, multi-currency billing, or a public API, closes a debate before it starts. Stakeholders stop asking why a feature was left out because the answer is already documented and was agreed on in advance. Without this category, every roadmap review reopens the same negotiation.
A worked example
Consider an AI-powered customer support platform preparing for its first paid release.
Must have: ticket creation, agent assignment, reply threading, and a working billing integration. Should have: AI-suggested replies and automated tagging. Could have: sentiment scoring and per-client custom SLA rules. Won’t have this quarter: a native mobile app and a public API.
Written out this way, the roadmap stops being a list of features in order of who argued loudest and becomes a document the whole company can reference, including sales, support, and leadership.
Running the exercise properly
MoSCoW fails when one person assigns the categories alone at their desk. It works when it is run as a short, structured session with product, engineering, and one commercial voice in the room together.
Write every proposed feature on its own card or line item. Score each one against the four categories as a group, not in sequence by whoever speaks first. Cap Must have at roughly half of available capacity before the session starts, and treat any overflow as a signal that the scope needs to shrink, not that the team needs to work faster. Revisit the categories at the start of every planning cycle rather than treating the first pass as permanent. Priorities shift as customers give feedback, and the framework should move with them.
The value of MoSCoW is not that it produces a perfect roadmap. No framework does that. Its value is that it makes the tradeoffs visible and forces the team to agree on them before the sprint starts rather than arguing about them after it slips.