It's very expensive to "improve quality in production." It's much more cost-effective to spend your quality dollars in development to ensure that you've created a design and process capable of delivering a great quality product. Then, all you have to do in production is maintain it. Each dollar spent to fix design issues in development will pay itself back in multiples by preventing bad units from ever being made or needing to be screened in production.
Here are some common misperceptions I've heard from operations and quality leaders arguing to delay working on quality until production. 
"I should wait until my product is more mature to address process issues."
Many engineers want to make sure a product is past DVT before really starting to work out the kinks in the process. Say you’re making a product with cosmetic requirements: it can’t be shipped with scratches. The parts will be prototypes in your first build, so they’ll arrive at your assembly line scratched. In your second build, you’ll waive scratches so you have parts to input (they’re just engineering samples anyway, right?). Eventually, it’s PVT, then Ramp, and you haven’t yet been able to validate that your final assembly line doesn’t scratch parts. And, of course, it does. At that point, you’ll try to figure out how to prevent the scratches. But by then, you’ll be throwing out a lot of defective units. Say you’re making 10,000 units a day — a 1% failure rate seems small, but that means 100 units a day are being thrown out. What if you made a fixture change now, in the first build, that would prevent all those scratches? You just saved 100 units a day at $200 each — $20,000 each day over two months of ramp.
"I can just screen out the bad units in production."
Okay. Maybe your organizational KPI isn't the final yield, but it should be. The company's stock price relies on things like operating margins -- and that includes the cost to produce the products you sell. If you own stock in your company, you are incentivized to keep those margins high. Also, you'll be a hero in your organization for doing so.
Treat the disease, not the symptoms. Each dollar to fix the issue in development is far cheaper than money spent in production to screen out units, particularly as you amass a bone pile of defective units that will have to be repaired or scrapped. That bone pile sits on the company's balance sheet and will also weigh down the company's financial performance.
Leverage development to design out quality issues that you would have to manage later
Think about assigning your development issues a priority rank based on what unblocks learnings and what will save you costs later. By spending a little more time (or leveraging Instrumental if you don't have time) to solve issues discovered in EVT, you can reduce tool revisions and have a more mature DVT, PVT, and ramp. By catching multiple issues early, you can make all of your tooling changes in one revision -- cutting your tooling revisions and their respective costs in half.
Managing issues in production
Occasionally, you will still have quality issues that surface in production where the best you can do is "manage" them. Perhaps it's a new problem or a latent one that you didn't discover. Then you are stuck managing those issues, which is the worst place to be because issue management is fragile. Managing an issue means that you accept a certain defect at a certain failure rate, and then you develop a process to reliably screen out those defects as early in the process and as cheaply as you can. Sometimes rework might be possible to recoup some cost. You will need to keep an eye on that process forever -- as you have turnover on the team or at the line, the process is at risk, and the issue could become unmanaged and leak defects down the line or escapes into the field. If you fix the root cause of these issues in development, you can save both the cost and the overhead of managing issues in production.