MoSCoW Prioritization

7 min read

In a Nutshell

You can't build everything at once, and you shouldn't try. MoSCoW is a simple framework for sorting requirements into four buckets: Must have (the system is broken without it), Should have (important but not a dealbreaker), Could have (nice to have if time allows), and Won't have (explicitly out of scope for now). The real power isn't the framework itself — it's the forced conversation about trade-offs. You cannot maximize availability, consistency, latency, cost, and feature count simultaneously, so MoSCoW makes you decide up front what you're willing to sacrifice.

2D minimalistic diagram showing four horizontal buckets stacked vertically labeled M, S, C, W from top to bottom, with example features sorted into each bucket, and a gradient from dark (critical) to light (deferred) shading

How It Actually Works

The Four Buckets

Priority	Meaning	Rule of Thumb	Example (Chat App)
Must have	Without this, the system doesn't work. It has no workaround.	If removing it makes the product unusable → Must	Send and receive text messages
Should have	Important, not critical. There's a workaround, even if it's painful.	Would cause significant inconvenience if missing → Should	Read receipts, typing indicators
Could have	Desirable, but the system is fully functional without it.	Nice to have, include only if time/budget allows → Could	Message reactions, custom themes
Won't have	Explicitly deferred. Not "never" — just "not this iteration."	Useful but out of scope for the current design → Won't	Voice/video calls, message translation

How to Apply It in System Design

In an interview or real design session, MoSCoW applies at two levels:

1. Feature prioritization — What functional requirements make the MVP?

For a food delivery app:

Must: Browse restaurants, place order, track delivery, process payment
Should: Ratings/reviews, order history, push notifications
Could: Loyalty rewards, promo codes, scheduled orders
Won't: AI-powered recommendations, social sharing, multi-language (for v1)

2. Quality attribute prioritization — Which non-functional requirements drive architecture?

This is the more interesting (and harder) conversation:

Must: Availability > 99.9%, payment consistency (zero lost transactions)
Should: p99 latency < 500ms for order placement, horizontal scalability
Could: Multi-region deployment, real-time analytics dashboard
Won't: 99.999% availability (too costly for current scale), zero-downtime deployments

The Trade-Off Conversation

MoSCoW's real value is forcing explicit trade-offs. In system design, common tensions include:

If you prioritize...	You sacrifice...
Consistency	Availability and/or latency
Availability	Consistency (in partition scenarios)
Low latency	Throughput (batching helps throughput but adds latency)
Low cost	Redundancy, and therefore availability
Feature breadth	Depth and reliability of each feature

The senior move is to say: "For this system, I'm prioritizing availability and latency over strong consistency for the feed, but I'll enforce strong consistency for payments." — applying different priorities to different parts of the same system.

2D minimalistic balance scale diagram showing trade-offs: one side has Consistency and the other has Availability, with Latency as the fulcrum, illustrating that you can't maximize all three

Common Mistakes

Making everything a Must — If everything is a must-have, nothing is prioritized. A good split is roughly 60% Must, 20% Should, 10% Could, 10% Won't.
Confusing Won't with Never — Won't means "not now," not "we'll never build it." It's a deferral, not a rejection.
Skipping quality-attribute prioritization — Teams often prioritize features but forget to prioritize how well those features need to work. This leads to over-engineered MVPs or fragile production systems.

Seeing It in Action

Scenario: You're designing an e-commerce platform. The stakeholder wants everything. You have 3 months and 4 engineers.

Feature MoSCoW:

Priority	Features
Must	Product catalog with search, shopping cart, checkout with payment, order confirmation email
Should	User accounts with order history, product reviews, inventory tracking with low-stock alerts
Could	Wishlist, product recommendations ("customers also bought"), promo/discount codes
Won't	Seller marketplace (multi-vendor), auction/bidding, AI chatbot support

Quality Attribute MoSCoW:

Priority	Attribute
Must	Payment consistency (ACID transactions, idempotency), 99.9% availability, data durability
Should	Page load < 2s (p95), auto-scaling for traffic spikes (Black Friday), basic monitoring/alerting
Could	Multi-region deployment, sub-second search, real-time inventory across warehouses
Won't	99.99% availability, zero-downtime deployments, edge caching for global users

Architecture impact:

Must-have payment consistency → SQL database with ACID transactions for the order/payment domain
Should-have auto-scaling → containerized app tier on Kubernetes or a managed service
Won't-have multi-region → single region is fine, saving significant complexity and cost
Could-have sub-second search → can defer a dedicated search engine (Elasticsearch) and use database queries for v1

Interview Questions

Q: You're designing a social media platform. How would you use MoSCoW to prioritize both features and non-functional requirements? Hint: Features: Must (post, feed, follow), Should (likes, comments, notifications), Could (stories, DMs), Won't (marketplace, live streaming). NFRs: Must (availability > 99.9%, eventual consistency for feed), Should (p99 < 300ms), Could (multi-region), Won't (strong consistency for likes — eventual is fine).
Q: Why is it important to prioritize non-functional requirements, not just features? Hint: Non-functional requirements drive architecture more than features do. Prioritizing 99.999% availability when 99.9% suffices adds redundancy, multi-AZ, and automated failover — all expensive. Prioritizing strong consistency when eventual is acceptable adds coordination overhead and latency. Over-specifying NFRs wastes engineering effort; under-specifying them causes outages.
Q: A product manager insists every requirement is a "Must have." How do you handle this? Hint: Ask: "If we can only ship three features on launch day, which three?" Force-rank rather than categorize. Alternatively, ask the consequence question: "What happens if this feature is missing at launch — do we lose users, money, or compliance?" If the answer is "it would be inconvenient," it's a Should, not a Must.
Q: How would MoSCoW prioritization differ for a banking app vs a social media app? Hint: Banking: Must-haves lean heavily toward consistency, security, auditability, and regulatory compliance. Social media: Must-haves lean toward availability, low latency, and scale. The same framework produces very different architectures because the priorities differ.
Q: You've shipped v1 with your Must-haves. How do you re-prioritize for v2? Hint: Last iteration's "Should" items become candidates for new "Must" items. Re-evaluate based on user feedback, production metrics (what's actually slow or failing?), and business goals. Some "Won't" items may now be relevant due to growth. The key is that prioritization is continuous, not one-time.

References

MoSCoW Prioritization — Wikipedia — origin and formal definition of the framework
System Design Interview – An Insider's Guide by Alex Xu — how trade-off discussions shape design interviews
Agile Estimating and Planning by Mike Cohn — practical prioritization techniques for software projects

Dive Deeper

Inspired: How to Create Tech Products Customers Love by Marty Cagan — Chapter on prioritization frameworks beyond MoSCoW (RICE, Kano model)
RICE Scoring Model — Intercom's quantitative alternative to MoSCoW
Trade-offs in Distributed Systems — Martin Kleppmann — video on how quality-attribute trade-offs play out in real systems