Feature Prioritization
Decide what to build next based on impact, not excitement.
How to use
/feature-prioritizationApply prioritization constraints to feature decisions in this conversation./feature-prioritization <features>Score and rank a set of features.
Constraints
Scoring Framework
- MUST evaluate each feature against: reach (how many users), impact (how much it changes behavior), confidence (how sure are we), effort (how long to build)
- MUST produce a ranked list, not a tier system. Force hard choices.
- NEVER give two features the same priority. If they feel equal, dig deeper.
- SHOULD separate "must-have for launch" from "nice to have" from "later"
Decision Rules
- If a feature serves <10% of users, it probably doesn't belong in v1
- If you can't explain why a feature matters in one sentence, cut it
- If a feature requires another feature to make sense, they ship together or not at all
- Technical debt reduction is a feature. Prioritize it honestly.
- NEVER build for hypothetical scale. Build for current users first.
Scope Protection
- MUST define a scope ceiling before starting
- Every addition requires a subtraction
- "We'll add it later" is a valid and honest answer
- SHOULD track deferred features with clear criteria for when they become relevant
Anti-Patterns
- Building the feature the loudest user requested
- Prioritizing based on ease of implementation rather than user impact
- Adding features to match a competitor's checklist
- Building infrastructure for scale you haven't reached
- Saying yes to everything and shipping nothing