TL;DR
You have one or more process problems that have been abstracted away into a proxy metric that is being used to "hold people accountable." This is almost always counterproductive, but is common in many company cultures. You will need to work as a team (including the product manager) to apply systems thinking to find the real problem, the right solution, and non-proxy metrics to measure your progress along the way.
Fiat Metrics Often Measure the Wrong Things
He expects a ratio no bigger than 0.15 (15% max of bug cards in an Epic)
Great! When he can run the process, write the software, perform the testing, and all the other stuff that goes along with that stuff himself, then he can set any fiat targets he likes. Until that happens, though, he needs to collaborate with the people performing the work to identify an acceptable level of quality and a measurable (and ideally executable) Definition of Done.
Besides being an arbitrary management target, it's not tied to anything actionable. You can measure it, sure. However, such metrics don't lead to actionable insights into the process or the underlying issues in what is essentially an X/Y problem.
Measure Outcomes Instead of Proxy Metrics
Aside from being more collaborative, this person needs to stop using proxy metrics and identify testable key results for the product and the process. Measuring "bugs" (which is sort of a hand-wavy term to begin with) is generally a proxy for "waste" in the Lean sense.
Essentially, this metric is saying:
Let's aim to waste 15% or less of our project capacity!
That's rather arbitrary, especially if the goal is lower than the industry standard. I won't argue whether or not the numbers are even valid since the metric itself is flawed.
Instead, this person should be measuring the outcome or key result that they're chasing. For example, if the project is over-budget because more time is spent fixing bugs than developing new features, you need a budget or labor metric rather than a proxy metric that counts bugs.
Likewise, if the company is losing money because of excess returns due to quality control issues or an inability to meet customer demand, then the metrics should be measuring returns or fulfillment issues directly rather than through a proxy.
Use Systems Thinking and Fix the Process
Bugs don't just happen. Even if you accept the premise that the percentage of bugs is inherently a problem, you can't measure your way out of a problem you don't have a root cause analysis for. In other words, demanding fewer bugs won't solve the problem; the way to fix the number of bugs is to fix the process that's allowing the bugs to happen or escape into production.
As a practical example, if the product manager and the project sponsor won't spend money on CI/CD tools or give the team sufficient slack in the process to perform test-first development, then bugs are inevitable. Bugs are prevented, caught, triaged, and more easily fixed if:
- Testing is baked into the design.
- Testing is automated.
- Every bug results in a new regression test to make sure it doesn't recur.
- Tests provide "living documentation" for the product's features and the Definition of Done.
- The product's architecture and development processes treats testing as a first-class objective.
- Budget, time, equipment, and labor are all made available to make quality control a first-class objective.
The majority of the time, this topic comes up because the budgetary authority or the person prioritizing the work has explicitly de-prioritized planning, testing, or tooling. These essentials are then replaced with human labor rather than automation or effective quality controls, and exhortations to "work smarter, not harder" or "hold people accountable." The latter almost always gets applied to the project team rather than the person actually accountable from a RACI model perspective for the budget, scheduling, prioritization, and other business-focused goals of the project.
I'd bet money that's the case here. Whether or not that's true, the whole team needs to carefully re-evaluate the process to find out why expectations aren't being met or excess labor is spent on fixing things post facto.
Dig for a root cause, which is almost always a process problem. Techniques like "The Five Why's" can often be helpful, but the point is to look at the whole process and drill down as far as you can, rather than just taking the issue at face value. Then the product manager and the development team need to collaboratively inspect-and-adapt until the root cause is resolved in a satisfactory and sustainable way.
