A shared scale (P0 to P3) for how badly a bug hurts, used to decide what gets fixed first.
Why it exists
Not every bug deserves the same urgency: a checkout that fails is not a misaligned icon, and treating them alike wastes effort or delays real fixes. Bug severity and triage exist to rank issues by impact, so the team fixes what matters most first and everyone agrees on what can wait.
How it actually works
Not all bugs are equal. A rough scale: P0 is critical, the product is down or losing money, fix now, wake people up. P1 is major, a key flow is broken for many. P2 is moderate. P3 is minor, cosmetic or rare. Triage is the act of assigning severity and deciding order.
This shared language lets a team agree instantly on urgency without arguing, and it's often a PM who sets or negotiates the severity.
A senior PM walks you through it
A junior PM, stuck
There is a bug ticket for Kacchi showing 0 taka on the menu and the comment thread has turned into a standoff: support says P0, the eng lead says P2, and both just tagged me to make the call. I do not want to overrule engineering or wave off support, and I cannot tell from the thread who is actually right.
Both of them are arguing from a real thing, they are just measuring different things. Severity is not how alarming the bug looks, it is impact: how many users and how much money or trust. There is one fact in this thread that settles it, and QA already posted it. This is the actual ticket. Read the three comments, then take the steps with me.
Bug TIF-482: Kacchi shows 0 taka on the menu page
Ticket
Severity: (blank)
Reporter: Arif (QA) Status: open Area: menu
Steps: open the menu on Friday promo. Actual: Kacchi price shows 0 taka. Expected: the promo price.
Comments
support Marking this P0. Customers see Kacchi at 0 taka right now. If they order at that price we eat the whole sale. This is live in production.
Rafi (eng lead) This is P2. It is a display bug on the menu card only. Checkout reprices from the database and still charges 649. No money moves. Ugly, not urgent.
Arif (QA) Confirmed Rafi. I added one to the cart, checkout showed 649 and the charge was 649. The 0 only appears on the menu card, never at payment.
Click a step to see the lines it points at.
Mistakes I've seen
Setting severity from whoever is most alarmed. Support was not wrong to worry, but P0 without the money-moves fact would have pulled engineers off real work at Friday peak for a display bug.
Reading 0 taka on the screen as 0 taka charged. The two are different systems, and Arif's checkout run is the only thing that tells them apart.
Splitting the difference to keep the peace. Severity is a judgment about impact, not a negotiation, and a made-up middle satisfies nobody and defends nothing.
Calling it P2 because no money moves and moving on. Every promo visitor sees a wrong price, and dismissing wide user-facing bugs as cosmetic is how trust erodes quietly.
In the ticket, set severity and say why: "P1. It is on the menu card for every promo visitor, but checkout reprices to 649 so no customer is charged 0. Fix it today, no incident." You just set severity from the one fact about impact instead of from the loudest voice, which is the whole skill of triage.
Where a PM meets this
You'll often own triage: calling severity sets what engineering drops everything for versus schedules for later.
Severity should reflect user and business impact, not how annoying the bug is to you; that judgment is part of the job.
Hear it in a meeting
"Is this a P1 or a P2? It's ugly but only affects a tiny segment."