Prioritizing Requirements

The Problem Prioritization Solves

A requirement list always exceeds capacity — capacity of the team, the budget, and (in interviews) the 45 minutes. Unprioritized lists produce designs that serve everything shallowly. Prioritization forces the question that shapes architecture most: what does the system do on day one, and what can wait?

MoSCoW: The Working Vocabulary

Class	Meaning	RideShare example
Must	System fails without it	Request ride, match, complete trip, capture payment
Should	Painful to skip, workaround exists	Ratings, trip history
Could	Nice if cheap	Fare splitting, saved places
Won’t (now)	Explicitly deferred	Carpooling, scheduled rides, driver chat

The W row matters as much as the M row — written deferrals stop requirements from sneaking back into the diagram mid-design.

MVP Slicing by Flow

Instead of prioritizing features in isolation, slice through the end-to-end flow:

 THE ONE FLOW THAT MUST WORK (day one)

 request → match → pickup → trip → dropoff → payment
    ✓        ✓        ✓        ✓        ✓         ✓

 EVERYTHING ELSE WAITS:
 ratings, history, surge UI polish, multi-vehicle classes...
 
 an MVP is a working spine, not a pile of half-built limbs

A system where matching works but payment doesn’t is not an MVP; it’s a liability. Vertical completeness beats horizontal coverage.

What Priority Changes in Architecture

Priority rewrites component treatment:

Requirement class	Architectural consequence
Must + correctness-critical (payments)	Strongest consistency, full redundancy, audit trail
Must + latency-critical (match)	Dedicated fast path, memory-resident data
Should (history, ratings)	Standard read replicas + cache; eventual fine
Could/Won’t	No box at all — but note the seam where it would attach

The last row is quiet leverage: designing a clean extension point for deferred features costs nothing now and saves rework later.

Triage Under Pressure

When time or budget shrinks mid-project (or mid-interview):

1. Protect the spine first — the Must-flow stays fully functional.
2. Degrade Should-features gracefully (hide the ratings tab; don’t corrupt them).
3. Never let a Could-feature consume Must-budget.

Systems die from inverted triage: polishing Could while Must rots.

Interview Framing

Interviewers hand oversized requirement lists deliberately. Scoring move: sort aloud into Must/Should/Won’t within two minutes, announce the day-one spine (“matching + payment must work end-to-end; history can be eventual”), then design only what the spine needs. This converts an unbounded problem into a bounded one — which is the actual skill being tested.