I would be interested to know what you mean by quality. Bugs, or something else?
If the concerns are related to quality that is visible to the end user, than I would focus on what you, as the product owner, can do to better define the acceptance criteria for your stories so as to preclude the problems you are having from being accepted.
Your role, as the Product Owner, is to give clear direction and provide continuous feedback on work completed. Make sure you and your team are communicating regularly about your goals and about story acceptance criteria, and make sure you are providing good direction and honest feedback on completed work. Make sure your team understands that they should be coming to you regularly to discuss any questions with execution and to clarify any ambiguity in stories/tasks. Make sure you make yourself available to them to listen to and answer these questions.
More specifically, here are a couple of ways to deal with different "quality" issues:
If it's bugs, work on your definition of done to ensure features are properly tested - including regression testing as they are integrated. Work on your own story writing skills and how you define up front and communicate the acceptance tests for your stories. Finally, if the requirements for testing and integration are clear, and the Definton of Done precludes buggy code from being accepted, and the team is failing to achieve this, then discuss the problem with your team at the next retrospective, and work with them to address it. Also, make sure you utilize your Scrum Master, who should be trying to figure out what's impeding the teams' ability to properly test the work done during an iteration.
If what you mean by a quality problem is not bugs, but something else, such as a request for information taking too long to execute, or a user interface that is not cohesive between screens, or something of that nature, here are a few tips for handling these types of problems:
First, again focus on developing a better DOD and better defining acceptance tests during backlog grooming and sprint planning. Also, work with your Scrum Master to ensure the team fully understands their responsibilities. If something is ambiguous or unclear, the developers are responsible for getting with the Product Owner or Customer to discuss and clarify. Ideally, everything is clarified during Sprint planning, but this might not always be the case, and it's important the developers know thy are responsible for clarifying the requirements and acceptance criteria for a story or task by discussing it with the PO (or directly with the Customer/end-user).
Second, if this functionality already exists (e.g. was part of an earlier story that was already accepted) and you're just not happy with the execution, then simply create another story to further clarify what it is you want. E.g. If requests take too long to return information, then write a story "I want X to happen quickly" and then follow the advice above to work with your team to clarify what will be acceptable for satisfying "quickly." Or if the issue is with user interface, write a story "The user interface should be consistent when switching screens." Again, clarification of either would ideally take place during Sprint planning or backlog grooming, as the team asks questions to estimate the story or as they start breaking it down into tasks to execute.
Finally, remember you are a team, and remember you meet regularly to discuss and improve your process. If you think the team would benefit from continuous integration, or pair programming, or some other development tool or strategy - I would suggest it during a retrospective as something that might be worth trying. Ultimately though, it is up to the development team to decide how they want to develop. As the PO you are responsible for setting the requirements for the end user, and the team is responsible for developing the solutions to said requirements.