MoSCoW method for product managers
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
The MoSCoW method is a prioritization technique I use to make scope tradeoffs visible. I sort candidate requirements into must have, should have, could have, and will not have for this time or release. The labels do not produce a ranking by themselves. They give the team a shared language for discussing value, risk, dependency, and the consequences of leaving something out.
I find MoSCoW most useful when a team has more plausible work than capacity. It can help during discovery, release planning, contract conversations, or a roadmap review. I do not use it to disguise a fixed decision as a collaborative exercise. The quality comes from the reasoning behind each category and from making the boundary around the decision clear.
Define the timebox and outcome
I start by naming the scope being prioritized. “The product” is too broad. I specify the release, customer group, problem, date or planning horizon, and outcome we are trying to achieve. A requirement might be a must have for a regulated launch and only a should have for an internal pilot. Without this context, two people can use the same label while making different decisions.
I also state the capacity and constraints I know about. That can include engineering availability, design or research work, operational readiness, legal review, data dependencies, support coverage, and a launch window. Constraints are not a substitute for customer value, but they change what a responsible commitment means.
Before sorting requests, I write the minimum outcome the release must deliver. I prefer an outcome such as “a new customer can complete the core workflow and understand what happened” to a list of features. This keeps the method focused on a usable result rather than on protecting every item that has already been requested.
Understand the four categories
A must have is necessary for the defined outcome or for a non-negotiable constraint. If removing it means the release cannot safely, legally, or meaningfully do what it promises, I treat it as a candidate must. I still ask for evidence. A loud request is not automatically essential.
A should have is important and valuable, but the release can still meet its stated outcome without it. A should may improve comprehension, efficiency, reach, or confidence. I record the cost of deferring it and the condition that would make it more urgent. Otherwise, should becomes a polite synonym for must.
A could have is useful if capacity remains after the essential work is complete. I do not call it trivial; a could can still be a worthwhile improvement. The label means its omission has a lower consequence for this scope and outcome. I use it to preserve good ideas without allowing them to crowd out the release’s purpose.
A will not have, sometimes called won’t have for now, is an explicit decision not to include the item in this timebox. I explain what the decision means and whether the idea belongs in a later review. This category protects the team from repeatedly reopening the same request and helps stakeholders understand that omission is intentional, not forgotten.
Use evidence instead of authority
For each item, I ask what customer problem it addresses, which users are affected, what happens if we defer it, what evidence supports it, and what dependency it creates. I distinguish a requirement from a solution where possible. “Customers need export” may actually mean they need to share a result with a colleague; the right response could be smaller than a complete export system.
I include different perspectives because each exposes a different risk. Customers and support can clarify the problem. Design can identify comprehension and accessibility concerns. Engineering can explain dependencies and failure modes. Operations, security, legal, and sales can surface constraints that a feature list hides. I do not let one function unilaterally define value, but I also do not treat technical or operational risks as obstacles to be negotiated away.
I write the reason beside the label. For example: “Must have because a user cannot complete the approval without it,” or “Should have because the manual workaround is available during the pilot.” A visible reason makes later changes easier when evidence or constraints change.
Facilitate the conversation
I usually begin with independent sorting or short written reactions before group debate. This reduces anchoring on the first confident voice. Then I review disagreements, starting with the outcome and evidence rather than asking who has more authority.
When an item is called a must, I ask what specifically fails without it. When everything is a must, I ask which commitment is being protected and what would happen if capacity drops. If a stakeholder says an item cannot be deferred, I ask whether the reason is customer harm, compliance, commercial commitment, operational readiness, or preference. Different reasons require different decisions.
I also watch for hidden bundles. A large feature can contain a must-have slice, a should-have refinement, and several could-have conveniences. Splitting the item can create a more honest plan than arguing about one oversized label. I keep the acceptance condition small enough that the team can tell whether the essential outcome is present.
Turn the result into a plan
The list is not complete until it changes how we work. I convert must haves into a clear release commitment with owners, dependencies, validation, and a definition of done. I attach a decision owner to disputed items and record the evidence that would change the category. For should and could items, I make the deferral visible rather than leaving them in an unowned backlog.
For the will-not-have category, I capture the customer or business context, the reason for deferral, and the next review point if one exists. I avoid promising that every deferred idea will eventually ship. Honest uncertainty is more useful than a reassuring but meaningless future commitment.
I revisit the categories when the outcome, evidence, capacity, or constraints change. A security finding can move an item into must. New research can show that a seemingly central feature is not needed for the first outcome. Reprioritization is not a failure of the original workshop; it is a response to learning.
Common mistakes
The first mistake is treating MoSCoW as a quota system, such as allowing only a fixed percentage of must haves. A small must category can be a useful signal, but an arbitrary quota does not reveal what the release requires. The second is calling every stakeholder promise a must without examining whether the promise is part of the defined outcome or constraint.
I also avoid using “won’t have” as a euphemism for “we will never consider this.” The category is about the current scope, and the distinction matters for trust. Finally, I do not publish the labels without their rationale. A table that says what we chose but not why will not help the team make the next tradeoff.
A practical starting exercise
I gather the candidate outcomes and requirements, define one release boundary, and ask each participant to sort the items independently. We compare the highest-disagreement items first, write the reason beside each decision, and split bundles that hide smaller slices. Then I check whether the must-have set still delivers a coherent customer outcome with the available capacity.
I publish the result with the assumptions, owners, and review triggers. MoSCoW works for me when it makes tradeoffs explicit and revisable. It is not a promise that every must will be easy, or that every could lacks value. It is a disciplined way to say what this decision protects, what it defers, and what we are consciously leaving out.
Next step
Build stronger product strategy, prioritization, and decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
