[edelans]

I have seen this problem solved with a super simple bug classification that anyone can leverage (even customer success) associated with priority and time to fix expectations.

YMMV, you have to adapt it to your usecase (B2B / B2C? contractual SLA? ...). But it can be something around:

  - P0 : a bug prevents a significant part of the customers (= paying users) to perform one of the core functionality of the product : at least one dev drops what he is doing right now and investigate, fix it himself or send it to someone responsible for the bug who should drop what he is doing right now and fix it. Target is to have it fixed in under a few hours. 
  - P1 : a bug prevents a few customers to perform an important yet non core functionality of the product: next dev available have a look at it. Target is to have it fixed in under a few days. 
  - P2 : a bug customers can live with (concerns few customers / there is a workaround / ... ) -> fixed in best effort, in practice, we fixed them when doing other features near that code. It can take a lot of time to fix them (if we ever fix them, and it's ok. The good thing about tech debt is that it's a debt you don't have to pay, when you remove/replace a feature for instance).

[tagspace]

This is actually exactly what we had in mind. Except that P2 gets put in a "won't fix" bucket.

- P0 means drop what you're doing and fix it now

- P1 means fix after you've finished what you're doing

- P2 means "won't fix" (but keep a note of it in case we ever get to that perfect situation where we have more time than features to build ;))