Product managers need to accommodate for solving for technical debt in the engineering capacity.
β There will always be the next-big-thing that your founder or CXO wants.
β There will always be a list of high-impact ideas that your sales or business team believe will help the company meet their quarterly OKRs
While the number can vary (~10%-20% of sprint capacity depending upon the product lifecycle state), certain % of your sprint bandwidth should be allocated to taking care of technical debt. If not, such debt can cripple the code-base with defects slowing down sprints & increasing customer tickets.
Most times, the buy-in becomes difficult due to tangibility of such refactoring. Zooming out from the code to the product, PM should talk to the engineering counterpart and build the rationale around tangibility e.g. how this refactoring is going to help shipping features faster or improve product performance.
Finally, while there will always be new fixes or changes coming in while the refactoring is on, itβs best to manage a change log to track changes from the time refactoring started and what additional changes have jumped the queue and gone into the codebase.
Previous Article
Opting for User-choice billing in Android : Is it worth the 4% cost savings?
Next Article