When you start building a custom application, ideas are never the problem. Login system, dashboard, notifications, PDF export... every feature feels essential when you're describing it. But you can't build everything at once, and definitely not on the same budget.
The MoSCoW method is there to force the call. It makes you put every feature into one of four buckets, and more importantly, own up to what won't get done.
What is the MoSCoW method?
MoSCoW is a prioritization system created by Dai Clegg in the 1990s. The idea is straightforward: every feature goes into one of these categories:
- Must Have: non-negotiable. Without it, the product doesn't work.
- Should Have: important, but the product can ship without it.
- Could Have: nice to have, if time and budget allow.
- Won't Have: we're not doing it. Period.
It's mostly used on agile projects, where priorities shift between sprints. But the principle works for any project that has more ideas than resources (which is every project).
From scoping to MVP, no detours
Must Have: the product doesn't exist without these
Must Haves are the features your product can't function without. If you're building an e-commerce site, that's the cart and checkout. If it's a management tool, that's authentication and data access. No Must Haves delivered = no delivery at all.
Should Have: version 2
Should Haves are features that bring real value, but nobody's blocked without them. Advanced filters, CSV export, dark mode. The product works fine without these, but it'd be better with them. Plan them for the next iteration.
Could Have: if there's time
Could Haves are the wish list. Nice improvements that don't fundamentally change the product. Build them if the schedule allows, cut them first when you need to save time.
Won't Have: no
This is the most useful category, and the most underrated. Explicitly saying a feature won't be built prevents misunderstandings and the same discussions coming back every two weeks. "We thought about it, we decided no, here's why." It's settled, everyone can move on.
What makes MoSCoW useful isn't the categories themselves, it's the conversation they force. When you lay all the features on the table and have to sort them, disagreements surface fast. And that's exactly what you want: better to argue about priorities at the start of the project than in the middle of development.
Why it works
Everyone speaks the same language
When a client says "this is important" and a developer hears "this is urgent", you have a problem. MoSCoW creates shared vocabulary. A Must Have means the same thing to everyone: without it, we don't ship. That cuts through interpretation.
Resources go where they matter
By focusing on Must Haves first, the team doesn't scatter. You don't spend three days on a badge system while authentication is unfinished. Sounds obvious, but without a prioritization framework, that's exactly what happens.
Priorities can shift
Your list isn't set in stone. A Should Have can become a Must Have if user feedback reveals something fundamental is missing. A Must Have can drop to Won't Have if a technical constraint makes it unrealistic. The ranking lives with the project.
The project stays on track
When every feature is classified, it's easier to spot the ones that don't actually serve the product's goals. This filter prevents building things "because the competitor has it" or "because it'd be cool".
How to set it up
Get the right people in the room
Start with a prioritization workshop. Put developers, the project manager, and the client-side people who know the business around the same table. You don't need 15 attendees, but the people who decide and the people who build need to be in the same room.
List everything, no filter
Write down every feature you can think of. Don't sort yet. Let everyone add their ideas, including the ones that seem minor. You make better decisions when you can see everything at once.
Classify together, and write down why
Take each feature and classify it. Debate will come naturally: someone will say "that's a Must Have" and someone else will say "no, that's a Should Have." That's normal and healthy.
What matters is that you document the reasoning behind each classification. In three months, when someone asks why a feature wasn't built, you can pull up the decision and its context.
Use a tracking tool
A Kanban board, a spreadsheet, project management software, whatever works. The point is that the classification should be visible to everyone and easy to update. If the ranking only exists in the project manager's head, it's useless.
Review regularly
The priority list isn't a document you write once and file away. Revisit it at the end of each sprint or at each project milestone. Priorities shift, constraints change, user feedback comes in. The classification needs to keep up.
Traps to avoid
Putting everything in Must Have
This is the number one trap. If everything is a priority, nothing is. I've seen projects where the Must Have column contained 80% of the features. At that point, the classification is meaningless.
One approach that works: cap the number of Must Haves per sprint. Force yourself to pick 3 or 4 at most. If something needs to come in, something else needs to come out.
Letting opinions override data
Everyone has preferences, and position in the company colors how you see priorities. The sales director will push for reporting features, the CTO will want to refactor the architecture. To keep the classification from becoming a power struggle, lean on data: user feedback, analytics, documented technical constraints.
Thinking MoSCoW is enough
MoSCoW is a sorting tool, not a complete project management methodology. It doesn't replace user stories, effort estimates, or retrospectives. It's one piece of the puzzle. Used alone, without the rest of the agile machinery, it loses much of its value.
MoSCoW won't solve all your prioritization problems. But it creates a framework that forces explicit choices. And in an application project, explicit choices always beat implicit ones.
