Working software is the primary measure of progress.
Management loves metrics. Lines of code. Code coverage. Defect rates. Whatever they can think of. The belief is that these metrics provide the manager with the sense of involvement and awareness. They often use these metrics to try to make predictions. Unfortunately, what they don’t realize is how much the metric hides.
You may have 100% code coverage with your test suite. But that doesn’t tell you if your code does what the business needs it to do. Defect rates on a downward slope imply that the product is maturing and approaching completeness. What it may mean is that fewer and fewer testers are being engaged in the testing process, or fewer and fewer features are being delivered, without respect for whether or not you are actually near completion. Virtually every metric has assumptions that must hold true for the metric to have meaning.
But in reality, none of that matters! All that really matters is that the business is able to make money (or save money) using what has been built.
So what metric should the management care about? What has been delivered, working. The software being delivered is composed of features. Those features have value to the business, as determined by the business.
The only metric that matters is, how much value has been delivered in a form that can be used?