Priority Level | Definition & Example | Action |
M (Must) | Critical to user experience, core function, stability or security. Example: payment errors, login failures, data loss | Assign a responsible team member and accountable owner, then resolve immediately. |
S (Should) | Connected to roadmap or business goals; not immediately fatal. Example: key feature requests, onboarding issues | Review in team meetings; optionally test with a subset of active users; assess usage or interview feedback to elevate to M or defer to C. |
C (Could) | Improves experience but not that critical. Example: UI tweaks, minor requests | Classify under ideas/improvement suggestions and re-assess in light of roadmap or product goals. |
W (Won’t) | Not feasible now or only relevant to a small user group | Keep in backlog, document why we’re not doing it now and under what conditions we might revisit it. |
Priority Level | Definition & Example | Action |
M (Must) | Critical to user experience or core function; affects stability or security. Example: payment errors, login failures, data loss | Assign a responsible team member and accountable owner, then resolve immediately. |
S (Should) | Connected to roadmap or business goals; not immediately fatal. Example: key feature requests, onboarding issues | Review in team meetings; optionally test with a subset of active users; assess usage or interview feedback to elevate to M or defer to C. |
C (Could) | Improves experience but not that critical. Example: UI tweaks, minor requests | Classify under ideas/improvement suggestions and re-assess in light of roadmap or product goals. |
W (Won’t) | Not feasible now or only relevant to a small user group | Keep in backlog, document why we’re not doing it now and under what conditions we might revisit it. |