As a product manager you lead your team’s and prioritize their work. One common challenge is to decide between spending time to improve current software versus releasing net new features. Improving current software sometimes also known as Technical Debt takes many forms: code can be refactored to be simpler, it can be optimized to run faster, it can have better test coverage for fewer bugs and so on.
On the other hand you as a product manager represent business and users who want new features within the software application to solve their problems. Net new or add-ons to existing features can be many things: new functionality, better user interface, new routes and APIs and so on. So how do you balance between the two?
Here are the five tips I’ve learnt so far to balance the two:
Make the outcome clear and obvious
One problem I often encounter is tech debt stories written by engineering that are full of low level details. Just like any other story type highlighting the benefit or outcome is important.
The value of fixing CI/CD pipeline issues or optimizing data access might be obvious to engineering team but without clearly outlining the benefit to none technical folks understanding their value and therefore getting them prioritized is more difficult. Delivering value takes many forms; if not upgrading to latest framework slows a team from adding new feature to the software or not fixing pipeline issues makes deployment a complicated and error prone project by itself then the value of doing all these tech debts are unblocking the team add new feature to the software quickly and efficiently. Stating this value upfront makes it easier to prioritize tech debt compared to other stories.
Fix small items on the go
One way to address smaller tech debt items are to fix them as part of building add-on features. By add-on features I mean new features built over some existing foundation. If the foundation needs improvement and it can be broken down into smaller tasks then some of those tasks can be tackled as part of building add-on feature without inflating it much. Breaking up what needs to be done and deciding to do it as part of a new feature vs a stand alone item needs expertise and for this I defer to the opinion of skilled developers and technical engineer leads that I know of.
Allow dedicated time for bigger items
If tech debt item is big enough that cannot be pegged to another story it is best to acknowledge it as such and allow clean up time before another project or a new milestone starts. Just like when one dish is done you allow time to clean up work surfaces and equipment in the kitchen before you start a new one. You can’t not make things dirty when you cook, but if you don’t clean things quickly, muck dries up, is harder to remove, and all the dirty stuff gets in the way of cooking the next dish.
One rule of thumb is to allow one week or even one sprint of dedicated tech debt work per every 4 to 5 sprint of feature work for a week. I’ve also seen ‘fix-it’ days equivalent to hackathon days that instead of building things quickly teams within the company focus on fixing items annoying them where they haven’t had time to fix them.
Document what’s fixed & list what needs fixing
Documentation is one of the most unappreciated and neglected part of software delivery and misinterpretation of Agile value of “working software over comprehensive documentation” hasn’t helped its cause. Having a central place to show what’s been fixed and a link to remaining list can quickly subside the confusion and worry about the amount of tech debt. This is something that needs commitment from engineers however developers usually don’t do a good job about this.
It’s an ongoing process
Like everyone else customers like the progress of new and improved software that makes their life easier and spending months to clear big tech debt and improve foundational items is hard to justify. That’s why balancing between feature work and tech debt is an ongoing process that can’t be done once and then set aside. There needs to be constant communication between product manager and the team on how to manage to avoid accumulation of too much tech debt to cripple development of future features.
Addressing tech debt doesn’t need to be a conflict point and a blame game of “you (product manager) won’t let us write good quality code because it takes too long” when it can be positioned as enabler of faster and better software development and delivered as a continuous part of software delivery.