The same applies to refactoring. “Centralize payment state management” is an output, while “raise the proportion of payment-related tasks completed within the originally estimated schedule from 3/8 to around 6/8” is an outcome. Once you have written this much, you can finally explain how refactoring connects to the business. In an organization that frequently runs payment conversion experiments, completing payment-related work on schedule means being able to run more payment experiments, more predictably, within the same period.
I think this is how the business value of refactoring usually becomes apparent. Refactoring itself does not generate revenue, but it changes the speed and stability of future changes. So, to explain its value, you also need to discuss what changes are expected in that code and how often they will occur. If you cannot explain this connection, refactoring can easily be seen as a matter of developer preference. If you can, however, it may become something the product team asks for first.
Rather than searching for one perfect metric, it is more realistic to look at two or three imperfect metrics that point in the same direction. For performance improvements, you could look at LCP p99, bounce rate, and the proportion of users moving from a product detail page to the cart together. All three are influenced by factors other than performance, but if all three move in the same direction at the same time, the likelihood of coincidence drops considerably.
“Let's refactor the payment module” can become “Only 3 out of 8 payment-related tasks are being completed on schedule, so let's raise that to 6 and run payment experiments more often.” “Let's reduce LCP p99 to under 2 seconds” can become “On the product detail page that 60% of orders pass through, 20,000 visits a day take more than 3 seconds to show the first screen, and those visits convert at half the rate, so let's start by reducing that.” And “Let's improve organizational productivity” can become “Let's reduce the waiting time that accounts for more than 2 of the 3 weeks it takes to deploy a feature.”
What problem does this solve?
How do we know that problem actually exists?
Why this particular approach?
How will we know that this approach has solved the problem?
