MoSCoW Prioritization:80 Feature Ideas, Build 5
MoSCoW prioritization for MVPs: how to turn 80 feature ideas into the 5 you actually build. The test for each category, plus the do-it-manually-first rule.
You have 80 feature ideas — 50 of your own and 30 more your users suggested. MoSCoW prioritization — Must have, Should have, Could have, Won't have — cuts those 80 ideas down to the 5 or fewer features that actually test your hypothesis. Everything else is a distraction, and most of it belongs in Won't have.
On top of your 80, competitors have another 20 features you don't. You can't build them all, and you shouldn't. Here is the framework for cutting ruthlessly — the test question for each category, what good and bad prioritization look like on real timelines, and the rule that stops you building things you could simply do by hand.
What is MoSCoW prioritization for an MVP?
MoSCoW sorts every feature into one of four buckets, each with a single test question. Answer honestly and the 80-item list collapses on its own:
| Category | The test | Task-manager example |
|---|---|---|
| Must have | If I remove this, can I still test my core assumption? If no — Must have. | Create a task with a deadline; mark it complete |
| Should have | Would early adopters still use the product without it? If yes — Should have. | Due-date reminders, task descriptions |
| Could have | Would anyone stop using the product if this didn't exist? If no — Could have. | Dark mode, custom colours, keyboard shortcuts |
| Won't have | Does this distract from core value? If yes — cut it explicitly. | Team collaboration, time tracking, calendar view |
Notice what fails the Must-have test in that example. Priority levels? Users can reorder the list manually. Categories and tags? Nice, not core. Recurring tasks? They can be created by hand. A feature is not a Must have because it's useful — it's a Must have because your hypothesis is untestable without it.
You're not building a minimum viable product
You're building a minimum testable product. That reframe changes everything, because it anchors every prioritization decision to your hypothesis instead of your vision. Vision is for version 10. If you can't state your hypothesis in one sentence, stop and fix that first — it comes straight out of the validation work you did before deciding to build anything.
And Won't have is where the discipline lives. It isn't a backlog — it's a list of features you are actively deciding not to build, each with a written trigger for reconsidering: after 100 users, after V1 is proven, or if users request it five or more times. Writing the trigger down is what stops the feature creeping back into scope in week two.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →The second pass: impact versus effort
MoSCoW gets you from 80 to a shortlist. The impact-versus-effort matrix gets you to five. Rate every surviving feature on two dimensions — how much it helps the user (1–10) and how many days it honestly takes to build — and four quadrants appear:
- Quick wins (high impact, low effort): these are your MVP.
- Major projects (high impact, high effort): do these after validation, never before.
- Fill-ins (low impact, low effort): polish, only if there's time.
- Time wasters (low impact, high effort): never build these — the custom reporting engine two users might want, the AI feature nobody asked for, complex permissions for edge cases.
Be skeptical of your own numbers. Founders systematically underestimate effort and overestimate impact — so add a 50% buffer to every estimate, challenge every 9-out-of-10 impact score, and keep total build time under four weeks.
Do it manually before you build it
For every feature that survives, ask one more question: can I do this manually for the first 10 users? If yes, don't build it yet. Send the email notifications yourself. Build the weekly report in a spreadsheet. Onboard each user on a personal call. Invoice by hand. Import their CSV for them.
Manual-first launches faster, teaches you what users actually need rather than what they say they need, and builds relationships with the early users who matter most. And it's a demand check in disguise: if you can't be bothered to do something manually for 10 users, why build it for 1,000? Only automate when you've done the task manually 10+ times, it takes more than 30 minutes each time, the pattern is consistent, and users explicitly ask for it.
What good and bad prioritization look like
Same task-manager idea, two scope decisions. The bad version: recurring tasks, subtasks, tags and categories, time tracking, team sharing, a mobile app, calendar view, Gantt charts — 90 days to build. The good version: create task, set due date, mark complete, simple list view, and a daily email digest sent manually to the first 10 users — 14 days. Shipped in two weeks instead of three months.
The cut features aren't the real cost anyway — the lost learning is. A CRM for freelancers cut from an eight-feature, 120-day plan to five features (add contact, add notes, tag status, simple search, manual CSV export) shipped in 21 days, and the users revealed something no roadmap predicted: they didn't want project management at all, they wanted follow-up reminders. A landing-page builder cut from a 60-day plan to five templates, editable text, and a basic form learned that users wanted more templates, not customization. Ninety extra days of building would have been ninety days building the wrong thing.
The five traps that refill your scope
- "But this is core to our vision." Vision is for V10. What's core to testing the hypothesis?
- "Users mentioned this." Which users? How painful? Will they pay? One person ready to pay outweighs ten "wouldn't it be cool if…" suggestions.
- "It's only two extra days." Two days becomes two weeks with debugging. Cut it; add it later if proven needed.
- "Competitors have it." They spent years building that. You're testing, not competing.
- "We can't launch without this." Yes, you can. What's the absolute minimum?
If your final list has more than five features, you're not done cutting. The best feature is the one you don't build: every cut ships faster, learns faster, costs less, and maintains easier. Your goal is not to build a product. Your goal is to test a hypothesis.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →Frequently asked questions
What does MoSCoW stand for?
Must have, Should have, Could have, Won't have. Each category has a test: Must have means the hypothesis can't be tested without it; Should have means early adopters would still use the product without it; Could have means nobody would stop using the product if it were missing; Won't have means it distracts from core value and is explicitly cut.
How many features should an MVP have?
Five or fewer. If your list is longer, you're not done cutting. Keep total build time under four weeks, add a 50% buffer to every effort estimate, and challenge every "must have" — most features belong in Won't have.
What's the difference between Must have and Should have?
A Must have is a feature without which you cannot test your core assumption — remove it and the experiment is dead. A Should have significantly improves the experience, but early adopters would still use the product without it, so it waits until after V1 validation.
When should I automate a manual process?
Only when you've done it manually more than 10 times, it takes over 30 minutes each time, the pattern is clear and consistent, and users explicitly ask for automation. Until then, manual work is cheaper than code — and it teaches you what users actually need.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.