Glossary
What Is the MoSCoW Method
The MoSCoW method sorts requirements into four categories, must have, should have, could have, and won't have, to give a team and its stakeholders one shared language for priority. It was formalized within the Dynamic Systems Development Method and remains its primary professional home.
What does the MoSCoW method mean?
The MoSCoW method is a prioritization technique that sorts requirements or features into four categories: Must have, Should have, Could have, and Won't have this time, with the interstitial Os added only to make the acronym pronounceable. Per the Agile Business Consortium, which stewards the Dynamic Systems Development Method the technique was formalized within, MoSCoW exists to reach a shared understanding with stakeholders on how important each requirement is before delivery starts, not after a dispute breaks out mid-project. Dai Clegg created the method around 1994 while working at Oracle, and it has since spread well beyond DSDM into Scrum and general product prioritization.
Why the MoSCoW method matters for product managers
Builders Camp's Product MBA certification quiz tests this directly, asking students to identify the goal of the MoSCoW method, with the correct answer describing it as determining which features must, should, could, and won't be included in a release. The value for a working PM is less about the four labels themselves and more about what they force a stakeholder conversation to do: instead of everyone calling their own request critical, MoSCoW makes the team agree on a fixed, small number of true Must haves before a deadline, which is the conversation that actually prevents scope creep. It also gives a PM a defensible answer when a stakeholder pushes back on a cut feature, since the category was agreed to openly rather than decided alone behind closed doors.
MoSCoW method example
A team with six weeks to ship a redesigned checkout flow uses MoSCoW to separate the payment method support that absolutely has to launch, the Must have, from a saved-address feature that would help conversion but is not required for launch, a Should have, and a guest-checkout analytics dashboard that is genuinely nice but can slip to the next release without anyone objecting, a Could have. Compared with a prioritization matrix built on impact and effort, MoSCoW answers a narrower but sharper question: given a fixed deadline, what is actually non-negotiable, which is exactly the question a launch date forces a team to answer honestly. Writing the guest-checkout dashboard down explicitly as Won't have this time, rather than leaving it unspoken, is what stops it from quietly reappearing in the sprint two weeks later.
How Builders Camp teaches the MoSCoW method
Product Manager Foundations, a 2 week bootcamp with 4 live sessions and 7 microlessons taught by Andre Albuquerque, teaches MoSCoW as one of the practical prioritization frameworks for scoping an MVP and trading off value, effort and risk. Product Strategy also uses MoSCoW when turning strategic bets into a roadmap with clear sequencing. See the Product Manager Foundations bootcamp for the full syllabus.
Bootcamps referred in this Guide
Frequently asked questions
What does each MoSCoW category mean in practice?
Must have means the release fails without it, Should have means it is important but not release-blocking, Could have means it adds value if time allows, and Won't have this time means it is explicitly out of scope for the current release, not forever.
Who decides what counts as a Must have?
The product manager typically facilitates the conversation, but the label only sticks once stakeholders across the team agree, since a Must have that only the requester believes in usually gets challenged later in the project.
How is MoSCoW different from a simple high, medium, low priority list?
MoSCoW forces a harder conversation because Won't have this time is an explicit category, not an implied bottom of a ranked list, which makes it much clearer what is genuinely out of scope for the current release.
Can the MoSCoW categories change during a project?
Yes, but changes should be deliberate and visible to the whole team, since quietly moving a Could have into Must have mid-project defeats the purpose of agreeing on priority up front.
Is MoSCoW only used in Agile projects?
No. It was formalized inside the Dynamic Systems Development Method, an agile delivery framework, but the technique works in any project that needs a shared, simple language for priority, agile or not.
What is a common mistake when applying MoSCoW?
The most common mistake is letting Must have absorb too many items, which recreates the same all-or-nothing pressure the method exists to avoid. A useful rule of thumb is keeping Must haves to a genuinely small, defensible list.
Sources
Andre Albuquerque
CEO of Builders Camp, SuperOperator, and other companies. Building products.
CEO of Builders Camp, SuperOperator, and other companies. Building products.
LinkedInMore guides by Andre AlbuquerqueLast updated 2026-09-26
Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.
Related guides
What Is a Prioritization Matrix
A prioritization matrix is a 2x2 grid, most commonly plotting impact against effort, used to rank options and decide...
Andre AlbuquerqueWhat Is the Four Actions Framework
The Four Actions Framework asks a team to eliminate, reduce, raise, and create specific factors an industry competes...
Andre AlbuquerqueWhat Is Kanban
Kanban is a visual method for managing work that focuses on limiting work in progress and maximizing flow rather than...
Andre Albuquerque