MoSCoW prioritization: 5 questions product teams ask on Reddit, answered
MoSCoW prioritization has been in circulation since Dai Clegg developed it at Oracle in the 1990s, and it remains one of the most recognizable ways to sort a backlog: must-have, should-have, could-have, won't-have. The glossary definitions are everywhere. The interesting material sits somewhere else.
Ask about MoSCoW prioritization in a working product community, and you get a sharper picture: where it fits, where it falls apart, and whether four categories survive contact with a room full of stakeholders. We went through the many prioritization threads on r/ProductManagement and pulled out the five questions that come up most often. Here are the answers, along with a view on where a product management framework designed in the 1990s sits in an era when engineering ships in days.
can support your team.
Book a demo
1. How do you handle MoSCoW's "could haves" without cluttering the backlog?
The original question was mechanical: When a could-have appears, does it belong in the same ticket as the must-have work, tucked into acceptance criteria, or somewhere else entirely?
The thread's consensus was to split them out. MoSCoW is a scoping exercise, so combining a could-have with must-have work inside one ticket undoes the categorization you performed. Could-haves become their own backlog items and get prioritized on their own terms.
The sharper answer went further, separating the four categories by evidence status rather than rank. A must-have is validated and ready to build. A should-have has been validated and is waiting for a slot. A could-have is unvalidated. A won't-have has been assessed and set aside. Under that reading, a could-have is a research task wearing a feature's clothes. It sits in the backlog because nobody has done the work to find out whether it earns a place.
That distinction is worth adopting, because it converts a vague middle category into a queue of open questions. It also explains why could-haves accumulate. Validating them requires customer evidence, and gathering that evidence is the first thing squeezed when a team is busy. Atlassian's 2026 survey of more than 1,000 product professionals found that 49% of product teams lack sufficient time for strategic planning, roadmap development, or data analysis.
2. Do product teams actually use MoSCoW in practice, or is it mostly theoretical?
Plenty of articles describe the ideal frameworks, but does anyone diligently practice one?
The answers were candid. Several practitioners described MoSCoW as useful at a specific scale and for specific work. One said it works well in the early stages of product development, then described outgrowing it as the stakeholder count climbed and building a bespoke approach instead. Another kept MoSCoW as the first cut, then layered separate values for criticality, urgency, and general priority on top of it to manage order within each category. A third used it for a narrow slice of the roadmap – UI improvements – while prioritizing other initiatives differently.
The pattern across the thread: MoSCoW is used as one instrument among many, adapted heavily, and rarely followed to the letter.
The Agile Business Consortium, the not-for-profit that maintains DSDM and acts as custodian of the method, reaches a similar conclusion from the opposite direction. Its own material observes that as the technique spread beyond DSDM, the rules governing its use became diluted and distorted. The version most teams practice has drifted from the version the framework describes.
The full discipline asks more than a workshop and four columns of sticky notes. DSDM sets priorities at three levels: the project, the increment, and the individual timebox. A single requirement can therefore hold three priorities at once. An archiving facility might be a must-have for the project, but a could-have for the first increment, since the solution runs perfectly well without it for a few months. Priorities are then reviewed at the end of every timebox and every increment, with anything unmet reclassified against what the next increment needs.
The method also comes with tests. The Consortium suggests starting with every requirement as a won't-have and making the case for promotion from there. For anything proposed as a must-have, ask what happens if it goes unmet, and treat canceling the project as the only qualifying answer. A blunter version of the same test: If you learned the night before deployment that a must-have could not ship, would you halt the deployment? Where a workaround exists, even a painful manual one, the item belongs further down the list.
So the honest answer is that most teams practice a simplified version. The four labels travel well. The rules that give the labels their meaning travel badly.
3. What do you do when two features land in the same MoSCoW category and you can only ship one?
MoSCoW sorts items into buckets. It does not rank them inside a bucket. Two must-haves compete for the same sprint, and the framework goes quiet, which is the point at which most teams reach for something else.
The workarounds that surfaced were practical. One product manager applied MoSCoW at the feature level alongside ROI and RICE scoring, then split each feature into version tranches: a first version covering the minimum, a second adding external polish, a third handling advanced functionality and automation. Others fell back on a tie-break criterion that sits outside the framework entirely, most often regulatory or compliance obligations, which outrank everything regardless of how the categories were drawn.
DSDM treats this scenario as a symptom rather than a puzzle. The Agile Business Consortium's guidance holds that a list where everything looks like a must-have usually indicates requirements broken down too coarsely. Decomposing a large requirement into sub-requirements tends to produce a mix of priorities, which restores the flexibility the technique is meant to create.
The framework also carries a capacity rule that most product teams have never applied. DSDM recommends limiting must-have work to no more than 60% of the effort in a project or increment, with a pool of could-haves at roughly 20% deliberately held as contingency. Above 60%, the Consortium treats delivery confidence as compromised unless estimates are known to be accurate, the approach is well understood, the team is established, and the environment carries low external risk. Reading against that rule, two must-haves competing for the final slot in a sprint is evidence about a decision made several weeks earlier, when the must-have pool was drawn too wide.
Two further rules from the same guidance work as genuine tie-breaks.
Dependency: A must-have cannot depend on the delivery of anything that is not itself a must-have, which resolves a fair number of ties on inspection.
Granularity: Acceptance criteria within a single requirement can carry different priorities. The Consortium's own example concerns restoring a service after a backup failure, where restoration within 4 hours is a should-have and restoration within 24 hours is a must-have. Splitting the requirement along that line releases capacity while keeping the commitment intact.
For a product leader, the useful takeaway sits upstream of the tie-break itself. Two items arriving at the same slot with nothing to separate them means the criteria that put them there were agreed loosely, verbally, or by people who have since moved on.
4. Does MoSCoW tell you why a feature matters, or only whether it is necessary?
One critique in the threads is worth more attention than it gets in most write-ups. MoSCoW measures necessity. It has nothing to say about the kind of value a feature delivers.
The example given was a security upgrade sitting next to a speed and usability improvement. Both might land as must-haves. They do entirely different jobs. The security work is a baseline expectation, invisible when present and damaging when absent. The usability work is a differentiator, part of why customers choose you and stay. A framework that files both under "must-have" has flattened the distinction that matters most for strategy.
This is why teams often pair MoSCoW with the Kano model, which sorts features by the kind of satisfaction they produce rather than by necessity alone. Plotting features visually, rather than reading a table of scores, also helps stakeholders who distrust a number they cannot interrogate.
For multi-team product organizations, the gap compounds. Each team applies the categories against its own context, and a portfolio view assembled from four teams' must-have lists tells a leader what everyone considers mandatory while revealing nothing about which of those items moves the strategy forward.
5. Is MoSCoW objective, or does it simply justify a decision that’s already been made?
The most pointed comment in any of these threads argued that frameworks frequently serve two purposes that have little to do with prioritization: justifying a decision already taken, and providing cover for the person who took it. The mechanism is straightforward. A framework looks objective, while the inputs remain subjective. Projections have upper and lower bands, and choosing the generous band for one item and the conservative band for another produces whatever ranking you were aiming at.
MoSCoW prioritization is more exposed to this than scored models, because a category assignment carries no visible work. "Must-have" is an assertion. The reasoning behind it lives in the head of whoever made the call and in the meeting where it was agreed, which was not minuted.
The fix has less to do with the framework and more to do with what surrounds it. A priority decision holds up when the evidence behind it is captured in the same place as the decision: the customer signals that prompted it, the score it received against agreed criteria, the strategic objective it serves.
Patrick Denison, Customer Success Manager at airfocus, describes the difference this makes in practice. “When someone challenges a decision, product managers can point to the specific customers who requested the work and the score it received against the team's agreed metrics, rather than defending a category assignment from memory,” he says.
That is the difference between a framework used as cover and one used for reasoning: traceability from customer signal to outcome.
Does MoSCoW prioritization have a place in the age of AI?
Yes, with a caveat about what it can carry.
We have seen this pattern before. In the 2000s, Agile made development dramatically faster, operations could not keep pace, and the constraint moved. The response was a new discipline, DevOps, built to match the velocity. The same shift is happening now. Bain's 2025 research found that writing and testing code accounts for 25 to 35% of the time from idea to launch, and AI is automating that slice rapidly. The remaining 65 to 75%, where discovery, prioritization, alignment, and planning live, is where product organizations now sit as the constraint. DORA's 2025 report found that AI adoption improves delivery throughput while degrading stability when the upstream process is not ready for it.
A shared vocabulary for scope negotiation still earns its place in that environment. Telling a stakeholder that their request is a could-have for this release is clearer than telling them it is medium priority, and MoSCoW's plain English remains its strongest feature.
The load it cannot carry is the decision itself. Four categories, assigned in a workshop, hold their shape for about as long as it takes for the next quarter's context to arrive. When engineering ships in days, a static categorization ages faster than the roadmap it produced.
What has to sit underneath the framework is the connected context that makes the categories meaningful and keeps them current: feedback linked to opportunities, opportunities linked to delivery, delivery rolled up to the objectives that justified the work. That is the argument for a product intelligence platform rather than a prioritization ritual. In airfocus, the Insights agent triages incoming feedback and links it to existing opportunities automatically, which is the validation work that leaves could-haves stranded when it has to be done by hand. Scoring apps produce a defensible number against criteria that the team agreed in advance. Bidirectional MCP pushes that context out to Claude, Copilot, and every other AI tool in the stack, so the agents doing upstream work are grounded in your actual product reality.
Frameworks are lenses. MoSCoW is a good one for negotiating scope against a deadline. The decision quality comes from what the lens is pointed at.
Ready to see what connected prioritization looks like?
Jeff Meyer
Read also
Prioritize with confidence
