Mastering Product Prioritization: From Requirement Levels to Incident Management

1. Requirement Prioritization

Requirement priority determines which features are built first, later, or not at all, based on business value or problem‑solving impact. Typically three levels are used:

P0 : Must be delivered immediately when resources are scarce.

P1 : Can be tackled after P0 when extra capacity becomes available.

P2 : Can be deferred or omitted for the current cycle.

When stakeholders ask why a request is not scheduled, teams should rely on an objective evaluation method consisting of two steps.

Step 1 – Strategic/Goal/Scenario Alignment

If the request serves a company‑wide strategy, it receives a higher priority.

If it supports a specific contract or revenue target, evaluate based on contract size and expected income.

If it addresses a particular user scenario, consider the affected user base, impact scope, and whether it touches critical user flows.

Step 2 – Implementation Considerations

Assess cost, difficulty, and value‑to‑effort ratio; low‑cost, high‑value items get higher priority.

Adjust priority for related requests that can be bundled together, reducing coordination overhead.

Adjust for dependencies, e.g., building an MVP first or completing backend work before frontend features.

Common analytical models that can be applied include the KANO model, VIGS method, Boston Matrix, RICE scoring, WSJF, effort‑impact matrix, MoSCoW, and Eisenhower matrix.

2. Test‑Bug Grading (Pre‑Production)

Test‑bug grades reflect the impact on test execution and differ from production‑bug grades.

Bug Grade

P0 : Must be fixed immediately; testing cannot proceed.

P1 : Urgent; affects core functionality and blocks testing.

P2 : High priority; should be fixed promptly but testing can continue.

P3 : Normal handling; can be scheduled according to personal plans and has minimal testing impact.

Severity Levels

Fatal : Critical failure that makes the software unusable (crash, cannot start, major functional gap).

Severe : Noticeable defect that blocks key functions but workarounds exist.

Normal : Minor defect that prevents a small feature or special operation.

Hint : Minor imperfection that does not affect current usage and can be addressed in a future release.

Key considerations:

Priority and severity are not always correlated; a low‑severity typo in a brand name may require fast correction, while a high‑severity bug that occurs only under extreme conditions might be deferred.

Bug fixing involves more than technical effort; project timeline, quality risk, and cost must be weighed, especially when a fix requires architectural changes.

3. Product Module Levels

Product modules are classified into three tiers, which serve as the foundation for online‑bug and incident grading.

P0 : Core functional flow essential for the product’s existence (e.g., product browsing, checkout).

P1 : Important but non‑core business modules that can be degraded (e.g., coupon redemption, user comments).

P2 : Non‑core processes that users can tolerate delays for (e.g., promotional activities, personal‑info display).

4. Online Bug Levels (Production)

Online bugs are graded based on user impact and response requirements.

P0 : Core business flow unavailable for all or most users, causing economic loss; response within 5 minutes, resolution within 1 hour.

P1 : Core flow unavailable for a subset of users or a high‑impact non‑core flow unavailable for all; response within 10 minutes, resolution within 24 hours.

P2 : Non‑core flow abnormal; may affect many users if prolonged; response within 1 hour, resolution within 1 week.

P3 : Minor non‑core flow issue; affects few users; response within 2 hours, resolution within 2‑3 weeks.

5. Online Incident Levels

Incidents encompass any production‑wide problem, not limited to software bugs (e.g., DDoS attacks, data‑center outages).

P0 : Core business flow down for all or most users, causing real economic loss; same SLA as online‑bug P0.

P1 : Core flow down for part of the user base or high‑impact non‑core flow down for all; response within 10 minutes, resolution within 12 hours.

P2 : Non‑core flow abnormal with potential wide impact; response within 30 minutes, resolution within 1 week.

P3 : Minor non‑core flow issue; response within 1 hour, resolution within 2‑3 weeks.

6. Closing Thoughts

Prioritization is a strategy for dealing with limited resources; even with abundant manpower, systematic prioritization remains essential.

Deeper reflection leads to ROI‑oriented thinking: how to maximize the value generated by development investment.