Taking an ultra-simplistic view...
Defects are introduced into a product by the development operation. We (or more often, management) might say "If I get better developers (for "better" developers read "better people and better processes and practises) I will get fewer defects". This is undeniably true, but only up to a point- At some unknown point on the curve you will not be able to reduce defects by hiring "better" developers, but you will still get defects because, as we all know (except for management) it is technically and practically impossible to produce defect-free code.
So you hire testers to ensure that a) the product does what it is supposed to do so you all get paid and b) they find every single remaining bug left in the code... Except that you have a similar curve- At one level, hiring better testers means they will find more defects, but just like you cannot guarantee bug-free programming, nor can you ever do enough testing to guarantee you have found all the bugs. Some will always remain. And it is the I.T. equivalent of Sods Law that even though the remaining defects are so obscure your testing coverage does not find them, on day 1 the users will (or thereabouts).
The trick is knowing whether your developers are sufficiently good and your testers are sufficiently good that you are producing the best possible outputs to the users, accepting the fact that there will always be some residual defects after testing no matter how much you do.
But let's suppose you have cause to believe that some element of the delivery operation is not operating to maximum possible quality and the users are seeing more defects than they could be. Where do you go from there?
Well, measure the amount and types of defect found in System testing, in UAT testing, and then after the product goes Live. Now you know how many "findable" defects there were in your product release. You can then assess why UAT didn't find the ones that were reported in Live, and why System testing didn't find the ones that were reported in UAT. Lastly you can assess why the defects made it out of the development shop at all.
You will get a wide range of effects and answers, but when you have them you can devise a cost/benefit analysis for mitigating whatever issues you find. Then when you have mitigated those effects to the point where spending more time or money wouldn't give you any appreciable difference in the residual defect rates you have achieved all you can achieve and you have the best practical delivery operation possible for you...
After that, issues will still get found, and users will still get annoyed and management will still ask why it is possible to deliver code with defects "even after spending all this money to make our delivery the best it can be", but you will know you have, as an organisation, done the best you can and you may rest easy at night :)