MoSCoW: A Simple Tool for Product Priorities
Feature Prioritization Series, Part 1.
Ever been in a product meeting where everyone nods in agreement about the “priority” of something—only to realize two weeks later you were all nodding to totally different things? That’s where the MoSCoW method comes in. It's a deceptively simple way to bring clarity and shared understanding to what really matters. And it’s not from Russia—it's just a quirky acronym.
Scott Burleson's Product HiveMind is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
What is the MoSCoW Method?
MoSCoW stands for:
Must-Have
Should-Have
Could-Have
Won’t-Have (for now)
It’s a prioritization framework designed to eliminate ambiguity when scoping a release, planning a minimum viable product (MVP), or just trying to herd the cats of cross-functional input into a coherent roadmap. MoSCoW helps teams align around what has to be delivered, what should be included if possible, what’s nice to have, and what’s explicitly out of bounds.
And here’s the critical distinction for us as product managers: these categories are for product features, not customer needs.
Why? Because customer needs don’t get prioritized—they’re constants. They’re the jobs the customer is trying to get done. Features, on the other hand, are our solutions to those needs—and that’s where tradeoffs come into play.
A Quick Origin Story
The MoSCoW method originated in the 1990s in the world of software development, specifically from the Dynamic Systems Development Method (DSDM), which was one of the early Agile frameworks. The extra O’s were thrown in just to make the acronym pronounceable (it has nothing to do with the city). But over the years, it’s become a staple in product management circles across industries.
Let’s Go Backpacking: A Tent Example
(Sorry, it’s another backpacking example - it makes it a bit more fun for me as I’ve gone deep into the minutia of this gear.)
Let’s walk through an example that doesn’t involve code for once. Say you're building a new product: a backpacking tent for solo hikers. Your market research shows that ultralight solo hikers want simplicity, protection, and performance—but are also weight-conscious and budget-aware.
Here’s how MoSCoW helps your product team align on what actually makes it into your first release.
✅ Must-Haves: Without These, the Tent Fails
These are your non-negotiables. Without them, your product doesn’t meet the core customer need: safe, dry, solo shelter.
Bug netting: No one’s going to tolerate mosquitoes swarming them all night.
Enough interior space for a hiker + gear: You’ve got to be able to lie down and keep your backpack out of the rain.
Highly waterproof material: If it leaks, it's a dealbreaker.
Notice how each of these features ladders up to a basic survival-level need. Without them, you’re not shipping a tent—you’re shipping regret.
🟡 Should-Haves: Important, but Not Show-Stoppers
If you can include these, great. They improve the experience significantly, but their absence won’t render the product unusable.
Zippered doors: They keep things easy and secure, but you could hypothetically use toggle ties in a pinch.
Free-standing setup: Adds flexibility in campsite selection, but users can stake it out.
Large vestibule: Great for cooking or gear storage, but not vital if the interior is sized right.
These are the things that could tip customer satisfaction into delight, but their omission doesn't send the customer running for a refund.
🟢 Could-Haves: Nice-to-Haves If Time and Budget Permit
These are the “it’d be sweet if…” features. If you’ve nailed your Musts and Shoulds and still have capacity, go for it.
Condensation vents: Avoids that sticky morning dew on your sleeping bag.
Rain-overhang on doors: Let’s you leave the flap open without inviting a storm in.
Ultralight titanium stakes: Cool gear-head flex, but regular stakes do the job.
Could-Haves often come from internal brainstorming or customer suggestions that sound great… if only the timeline were infinite.
🚫 Won’t-Have (for now): Clearly Out for This Release
Now this is the underrated hero of the whole MoSCoW method. By clearly stating what won’t be in the tent—for now—you avoid ambiguity, scope creep, and wishlist drift.
Carbon fiber poles: Too expensive and prone to breakage. We'll revisit later if demand is high.
DCF (Dyneema Composite Fabric) fly material: Ultra-premium, but cost-prohibitive and doesn’t fold well for packability.
Slip-proof tent floor: Could be nice, but not essential and adds complexity.
Explicitly naming what’s not included de-risks the roadmap. It sets expectations and clears the runway for Must-Have execution. And guess what? It also prevents you from having to say "no" 27 times in Slack threads—because you’ve already said it in the plan.
Using MoSCoW for Software Too
Of course, the MoSCoW method shines just as much in software. Whether you’re building a new mobile app, a SaaS platform, or an internal tool, you can bucket your features by release.
Must-Have for v1 might include user registration, core workflows, and error handling.
Should-Have might be advanced search or integrations.
Could-Have could be dark mode or gamification elements.
Won’t-Have (for now) might be things like machine learning recommendations or third-party APIs that need legal sign-off.
Remember: in both hardware and software, MoSCoW is about this release—not the product forever. Just because it’s in the Won’t-Have bucket today doesn’t mean it won’t come back into scope for v2.
The Real Value: Alignment and Focus
The biggest superpower of MoSCoW isn’t just categorization—it’s alignment.
When product managers use MoSCoW with design, engineering, marketing, sales, and leadership, it creates a common language. It surfaces tradeoffs early. It clarifies what's in and what's out—and why. And when a stakeholder says, “Hey, can we just squeeze this in?”—you’ve got a shared framework to say: “We decided that was a Won’t-Have for now. Here’s why.”
It also trains teams in the art of saying no, a core discipline of product leadership. MoSCoW gives you the structure to say it without drama.
MoSCoW vs. Other Prioritization Methods
MoSCoW is great for clarity, but it doesn’t give you a score or a business case. That’s where tools like Opportunity Scoring, Kano, or RICE come in. Use MoSCoW to align your team and stakeholders on categories, then dig deeper with other methods if you need to rank things by ROI or effort.
Final Thoughts
This is the first article in a series covering various prioritization methods.
I like MoSCoW because it’s just so simple. People tend to make product management complex, but it doesn’t have to be.
MoSCoW won’t give you a quadrant or a weighted average. But it’s one of the fastest ways to get your team out of hand-wavy “yeah, that’s important” land and into “this is what we’re building.”
Just remember:
Prioritize features, not customer needs.
Use it for release-level planning—don’t turn it into a product backlog dump.
Be ruthless with your Won’t-Haves—they’re your best friend for staying focused.
Whether you're shipping code or stitching rainflies, MoSCoW helps you communicate priorities without ambiguity. And in product management, I’ll take clarity over something fancy any day.