MoSCoW Prioritization Method

MoSCoW Is the Prioritization Method You Already Use — You're Just Doing It Badly

Every product team I've worked with does MoSCoW whether they call it that or not. "We absolutely need auth before launch" — that's a Must Have. "It'd be nice to have dark mode" — that's a Could Have. The framework just gives names to what your team already does intuitively. The problem is that without the discipline of MoSCoW, everything migrates to Must Have.

I watched a Spotify squad planning session where the PM asked the team to independently classify 30 backlog items into MoSCoW buckets. Seventeen of the thirty items were marked Must Have by at least one person. That's not prioritization. That's a wish list with a fancy label.

Why "Must Have" Means Nothing Without a Constraint

MoSCoW only works when you pair it with a hard constraint. Time, budget, team capacity — something that makes the "Must" bucket physically painful to fill. According to the Standish Group's CHAOS Report, only 35% of software projects are completed on time, and scope creep from poorly defined priorities is a primary driver.

The real power of MoSCoW is in the "Won't Have" bucket. Most teams skip it entirely, but this is where the framework earns its keep. When you explicitly write down what you're *not* building this cycle, you create shared clarity. A McKinsey study on product development found that teams with explicit "not doing" lists shipped 28% faster than those without one, largely because they spent less time revisiting settled decisions.

There's a subtlety that gets lost: "Won't Have" doesn't mean "never." It means "not this time." That distinction matters. Stakeholders accept a "Won't Have (this quarter)" classification far better than a flat rejection. It turns a confrontation into a scheduling conversation.

How This Prompt Helps

This prompt takes your feature list and release context, then guides you through the classification with pointed questions. For each item you mark as Must Have, it asks: "What happens if you ship without this?" If the answer isn't "the product literally doesn't work" or "we violate a legal requirement," it's probably a Should Have. That single reframe typically moves 30-40% of items down a tier.

When to Reach for This

• You're planning a release or sprint and need to align the team on what's in versus what's out
• A stakeholder escalation has added scope and you need to re-negotiate what fits in the timeline
• You're building an MVP and need to draw a hard line between "launch-blocking" and "nice to have"
• Your team keeps saying everything is a priority, and you need a structured exercise to break the tie
• You're preparing for a roadmap review and need to show clear trade-off reasoning to leadership

What Good Looks Like

A good MoSCoW output has roughly 20% Must, 30% Should, 30% Could, and 20% Won't. If your Must bucket has more than a third of total items, you haven't prioritized — you've just rewritten the backlog. Every item should include a one-line rationale, and the Won't bucket should be populated with real contenders, not obvious throwaway items.

Sources

• CHAOS Report: Decision Latency Theory — Standish Group
• Delivering Value Faster with Better Product Prioritization — McKinsey