← Go Back

Feature Prioritisation

What is feature prioritisation?

Feature prioritisation is the process of deciding which features or work to do first, which to do later, and which not to do. It uses a mix of user value, business impact, effort, and risk so you focus limited resources on what matters most.

Use it when: you have more ideas or requests than capacity. Prioritisation makes the order explicit and defensible instead of reactive or political.

Copy/paste template (simple)

  • Must have (this release): Without these, we don’t ship or the product fails. List 3–7.
  • Should have: Important but not blocking. We’ll include if time allows.
  • Could have: Nice to have. Backlog for later.
  • Won’t have (this time): Explicitly out of scope. Stops scope creep.

Review and re-prioritise when you learn something (e.g. from user research or A/B testing).

Why feature prioritisation matters

  • Focuses the team on the few things that deliver the most value.
  • Makes trade-offs visible so stakeholders understand what’s in and out.
  • Reduces thrash and “everything is urgent” by having a clear order.
  • Connects work to problem statements and strategy.

What good feature prioritisation includes

Checklist

  • [ ] Criteria – value (user/business), effort, risk, dependency. Define what “high value” means for you.
  • [ ] Visible list – backlog or roadmap that the team and stakeholders can see.
  • [ ] Revisited – prioritisation isn’t set once; it updates as you learn.
  • [ ] Tied to strategy – the top items support your product and business goals.
  • [ ] “Won’t do” is explicit – so you don’t keep revisiting the same ideas.

Common formats

  • MoSCoW: Must / Should / Could / Won’t. Simple and good for scope agreement.
  • RICE: Reach × Impact × Confidence ÷ Effort. Use when you want a score and can estimate.
  • Value vs effort: 2×2 matrix (high/low value, high/low effort). Quick wins in high value, low effort.
  • Kano: Basic / Performance / Delight. Helps separate “must have” from “nice to have”.

Examples

Example (the realistic one)

Context: You’re launching a new dashboard. Must have: Log in, view key metrics, one core action (e.g. “export report”). Should have: Filters, date range, second export format. Could have: Customisable widgets. Won’t have this time: API, white-label, mobile app. You’ve agreed this with stakeholders and linked each item to a user story or problem statement.

Common pitfalls

  • Everything is P0: no real trade-offs. → Do this instead: force rank; only a few things can be “must have”.
  • Loudest voice wins: prioritisation by stakeholder pressure. → Do this instead: use criteria (value, effort, evidence) and make the order visible.
  • No “won’t do”: the backlog grows and old ideas keep returning. → Do this instead: keep a “won’t do (this time)” list and revisit only when context changes.
  • Ignoring effort: high value but impossible to deliver in time. → Do this instead: include effort (or confidence) in your criteria; slice or defer if needed.
  • Never revisiting: priorities set once and never updated. → Do this instead: re-prioritise after research, launches, or strategy changes.
  • Prioritisation vs roadmap: prioritisation is the order of work; a roadmap is when you plan to deliver it (themes, milestones, dates).
  • Prioritisation vs backlog: the backlog is the list; prioritisation is how you order it. A well-prioritised backlog is the result.
  • Prioritisation vs strategy: product strategy sets direction; prioritisation decides what to do next within that direction.

Next step

Take your current backlog and apply MoSCoW (or value vs effort) with your team. Make “must have” and “won’t have this time” explicit. If you don’t have a clear problem statement for the release, write one so prioritisation is tied to a goal.

Related Terms