Skip to content
Gallery
10 Feature Prioritization Methods
Prioritization for All
Prioritization Tool Kit
About me
Share
Explore
Prioritization Tool Kit

icon picker
Method 3: Thresholds

Prioritize your features based on when to start, like starting fixing bugs when they reach the allowable threshold.
Modified from
Product School
⁠
-
Feature Prioritization Template
⁠
. And inspired by
Rushabh Doshi
⁠
, CPO at Digit.
⁠
Change: Bug Priority
See results auto-ordered in: Bugs (features)
Priority Levels
Level
Description
Bugs allowed in this priority
Bug count
Above the threshold?
1
P0
Look at this NOW
00
0
1
Yes
2
P1
Fix within 24 hours
00
2
1
No
3
P2
Fix within a week
00
5
2
No
4
P3
Fix within next sprint
00
8
1
No
5
P4
Catchall
00
10
3
No
There are no rows in this table
⁠

Bugs (features)
Request Name
Bug Priority
1
F2: Import functionality
P0
2
F1: New billing page
P1
3
F3: Video calls
P2
4
BNS-684: Notification panel redesign
P2
5
F4: Security upgrade
P3
6
F5: Item comments
P4
7
F7: Localization of mobile app
P4
8
F8: Multi-location Management
P4
There are no rows in this table
⁠


About Thresholds Prioritization

Priority 0. Look at this NOW. This priority should typically be tied together with an on-call rotation so that someone gets alerted. Services going down, significant parts of functionality going unavailable, major security problems—these sorts of things should result in a P0 bug. P0 bugs should be rare enough to warrant a formal review process around what caused the problem, its discovery, fixes applied, and lessons learned.
Priority 1. Fix within 24 hours. Examples include significant flaws in the product, bugs that affect a subset of the user base, bugs that impact the brand in a significant way.
Priority 2. Fix within a week. Minor problem, but it would be good to get fixed before then next major release of the feature goes out.
Priority 3. Fix within the next sprint (typically 2 weeks, but as long as a month).
Priority 4. Catchall priority for things that should go into the next sprint. Expect these bugs never to be looked at unless they get upgraded to P2s. Different teams prefer to have these lying around because they are a documentation of everything wrong or delete them because they are mostly useless.

Thresholds Links

⁠
Software Quality, Bugs, and SLAs
A guide on how to keep your engineering team on track by a former Director of Engineering and Product Management at Facebook.
coda.io
⁠
⁠

⁠

Next up:

⁠
Method 4: Value vs Effort
⁠
⁠


Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.