It depends on the company. On an actual production app with lots of users, bug triaging is very organic. Almost anyone at the company can determine how serious a bug is from what I’ve seen in those environments.
On more prototypal apps, where there aren’t many users (if it all) other than the devs/designers/analysts/qa, it can be a true shit show. No one has a sense of what’s important and the priority list is largely dependent on whoever has seemingly the most authority.
If you are working with few users, it’s better to first make sense of priorities of the team members (the team members are synthetic/faux users that have other motivators than just getting the most use out of the app). Without users, it could be that the bug your primary stakeholder found is THE MOST IMPORTANT bug, when in fact it’s not. Or, a super important bug that the dev team ignores because there are no users for it to matter yet. This is murky territory, it’s basically fantasy-land since you are building a small group’s vision (which has yet to be, you know, used).
If you have users, then you don’t even have to ask this question. Just put yourself in the average user’s shoes and determine if the bug makes the app unusable, confusing, inconvenient, etc. If you actually generate revenue from the app, then it’s even easier since you’ll know if the bug is not delivering what the user paid for lol (your showstopper critical bug).
I’d argue it’s worth sitting down with the team and first determining what ‘quality’ means for you guys. Having zero bugs doesn’t necessarily mean quality control. You could be fixing something that’s shoddy to begin with, in which case, triaging bugs doesn’t actually get you the quality control you’re looking for. You’d still be shipping something rickety. Anyways, I’ve digressed too far.
