Curious: what domain do you work in? In mine (consumer webapps, and now consumer mobile), "never shipped a bug" is a meaningless phrase, because "a bug" depends on how millions of consumers respond to it, and very often code that is deliberately buggy from a technical POV (dropping data on the floor, for example) actually ends up with better metrics.
I used to work in financial software, where things were very different, and before that I'd interned at a company that did avionics software, which is a whole other ballgame. I just find it interesting that the definition of "bug" can vary so greatly across domains in what's commonly thought of as a single industry.
For the term to be meaningful, 'bug' needs to be more tightly defined - a discrepancy between the specification (both as stated and intended[1]) and the actual behaviour of the code is a bug. Now, if the wrong behaviour is actually beneficial, then there's nothing wrong with changing the spec, that's basically the central idea in agile - but the idea that if given a spec to make the blue button green, you make the button green - and if users then react negatively to that, then that doesn't mean you shipped a bug in any meaningful sense. It also doesn't mean you shouldn't change it back, quickly, but the developer did not ship a ship.
1: Just because the specification doesn't specifically state "shouldn't crash if the user inputs a negative number", it's understood that the program shouldn't crash given any user input.
I used to work in financial software, where things were very different, and before that I'd interned at a company that did avionics software, which is a whole other ballgame. I just find it interesting that the definition of "bug" can vary so greatly across domains in what's commonly thought of as a single industry.