Prioritization: Efficiency vs. Feature Velocity

In my experience, a 50/50 split between tech debt and features is rarely optimal; it usually signals that technical friction is silently eroding our velocity. As a PM at Google, I would approach this by first quantifying the cost of inaction. If our team spends half their time fixing legacy issues, our feature delivery rate is likely lower than potential, and our reliability metrics may be degrading. I would introduce a data-backed narrative to stakeholders, showing how specific debt items directly correlate with slower release cycles or higher incident rates. Instead of demanding a hard 50/50 split immediately, I would propose a dynamic allocation model. For instance, we could dedicate 80% of capacity to high-impact features for two sprints to meet a quarterly OKR, then allocate 60% to refactoring in the following sprint to clear the bottleneck. This ensures we deliver value while systematically addressing the root causes of inefficiency. By framing debt reduction as a velocity accelerator rather than a cost center, we align engineering efforts with business outcomes. Ultimately, the goal is not to eliminate debt entirely but to manage it so it never exceeds 20-30% of capacity, ensuring sustainable growth.