Strategies for Balancing Innovation and Technical Debt

The app ecosystem has changed many things in the world of software development, one major shift being the ability to rapidly push out software updates to your entire user base. Many apps are updated every week or two, and before the end user clicks that “Update” button, they have the chance to see exactly what’s different in the shiny new version of each app. From update to update, you’ll find a common theme: “bug fixes” and “performance improvements” appear just as often (if not more often) as new features or functionality.This doesn’t mean these app developers are shipping junk software to the masses and then fixing things when users start complaining. Rather, it means these companies are investing in their technical debt, just in a far more public space than enterprise solutions and SaaS products that don’t need to broadcast to users what they’re up to.[Tweet "You don’t have to do anything wrong to amass technical debt."].

Primary Sources of Technical Debt

• Usage growth. This is the greatest source of technical debt. As your solution is used more and more, it suffers growing pains, capacity issues, and performance woes that must be addressed to accommodate the additional workload and storage requirements.
• The passage of time. Third-party resources (libraries, platforms, operating systems, etc.) you depend on age and must be updated themselves to support new technology, repel new viruses, and give your own software new capabilities to incorporate.
• Cleaning up your messes. Nothing is perfect the first time out, so adding new features and functionality inevitably creates imperfections to fix and processes to optimize.

Technical Debt and Product Innovation: A Necessary Pairing

While the first two sources of technical debt are essentially necessary evils, it’s the third category that creates the most challenges for product management.You want to deliver new features. Your developers want to build new features. Your QA department wants to test new features. And your sales and marketing teams definitely want to talk about new features. This is why you’re here - you all got into this business to come up with new stuff and deliver it to customers.But with every new feature you add, you’re also adding a complexity cost. It’s one more thing to add to the testing matrix. It’s one more item that creates dependencies. It’s one more thing to maintain and become a source of future technical debt.“Complexity cost is the debt you accrue by complicating features or technology in order to solve problems,” says Kris Gale of Yammer. “An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer. Sometimes complexity is a necessary cost, but only organizations that fully internalize the concept can hope to prevent runaway spending in this area.”As your product matures, new functionality runs an additional risk. When you’re not simply improving an existing element, you’re adding one more widget that can water down your value proposition, confuse your sales efforts, distract users, and suck resources away from the core elements of your product.And while there’s a natural tendency to keep adding features, this tendency can easily lead to feature bloat.“I feel very strongly that the depth of our features, not the scope of them has been what has made Sketch popular,” says Pieter Omvlee of Bohemian Coding. “We’ll gain more fans with smart little touches we add to existing features than bolting on more and more features. Bloat is something we want to avoid at all costs.”

Strategies for Balancing Technical Debt and Innovation

Figuring out when to add something new instead of fixing something old is tricky business. Here are some ways to figure out how to make it happen.

Prioritize customer needs (not wants)

Customers are a great source for ideas, but they are not always a source for great ideas. They’re usually not well-versed in the complexities of your products or even software development in general. So instead of letting them design the solution, use their expertise to fully articulate the problem.Customer Want: The customer wants a button for every possible person or group they might send a message to.Vs.Customer Need: The customer needs to send some messages to the entire team, some messages to specific subgroups, and some messages to individuals.It might very well be that dedicated buttons are the best way to handle message routing…or it could be an unmitigated disaster that doesn’t scale, slows down the UI, and is impossible on a mobile client version of your app. It’s your job to figure out how to meet the customer’s needs without creating problems your dev team will be wrestling with for years to come.The key to making this all work is letting your customers know that you’re going to address their needs (not just doing exactly what they asked you to do) and that you’re going to accomplish this without ransoming your future flexibility for a quick win today.[Tweet "Customers are a great source for ideas, but they are not always a source for great ideas."]

Encourage good coding practices

As the product manager, you’re sometimes viewed as the slavedriver whipping the team to deliver specific functionality by a certain date (or at least the person who told the project manager to whip them). If you treasure hitting dates and pushing code above all else, those values will eventually trickle down into the engineering teams supporting you.While this may initially seem great, sloppy coding and half-baked testing procedures will rapidly lead to both unhappy customers and development efforts hamstrung with supporting the spaghetti code the engineering team cranked out on version 1.0. This scenario can be avoided by supporting — or even demanding — that your engineering teams are employing proper coding practices and spending the time on code reviews, unit testing, and regression testing before they even think about shipping.If you make it a requirement, it will happen. If you leave it up to them, you never know. So take the hit on delivery dates, set expectations with sales and customers, and make sure you’re shipping something that will be far easier to support in the future. It’s all about taking your medicine today so you’re healthy tomorrow.

Get organizational alignment on routine debt management

One of the trickier tasks you’ll face is convincing your own organization that it’s worthwhile to tackle technical debt. While you may have a few prudent voices on your management team, the focus on hitting targets, creating press release fodder, and pleasing customers can often drown them out.Therefore it’s essential to make addressing technical debt part of your company’s routine. Whether it’s every release or every other one, there should be an expectation that managing technical debt is an expected and regular part of the process.One way to reinforce this is working from a single backlog, with new features and technical debt items sitting side-by-side in the queue. This keeps them visible for everyone and doesn’t make it seem like they are “something extra” that people need to work on and slot into the product roadmap.

Remember that not all technical debt is bad

It’s natural to assume that technical debt is a negative force in your product that should be eradicated at all costs. But just like you shouldn’t eliminate ALL cholesterol and fat from your diet, getting to “zero technical debt” isn’t a realistic or healthy goal.“Up to 40 percent technical debt for early-stage companies and up to 20 percent for more mature organizations is actually healthy,” says Brian York of Bliss. “Once you cross over those thresholds, you risk releasing buggy products that will negatively impact your relationship with customers.”The reason why these levels are OK is because snuffing out every speck of technical debt will bring your innovation to a screeching halt. Of course you want to future-proof whenever possible, but not at the expense of having your product stagnate in the market.“Obsessing about technical debt leads to shipping releases that users don't care about, paving the path to irrelevance,” says Mathew Lodge of Weave.works. “There needs to be a balance between paying off technical debt and making the product better for users and buyers, and an understanding of when clearing technical debt helps improve customer experience.”[Tweet "Getting to “Zero Technical Debt” isn’t a realistic or healthy goal"]

Notice early warning signs that technical debt is taking its toll

You know it’s out there, lurking, waiting to suddenly throw a wrench in your plans and derail a release. But is there a way to predict when it’s time to take on a major technical debt project?One indicator that technical debt is moving from nuisance item to stumbling block is when your team’s velocity or throughput is slowing down. Says management consultant Johanna Rothman:

“If you have a lot of Technical Debt and you’re growing your Technical Debt, then your velocity is going to go down and your throughput is going to go down. If you don’t look at it and you do not look at it over time (trends are everything!) you will lose the big picture...I also want to look at velocity to say: Are we losing ground from iteration to iteration? Not to punish ourselves… but to see if we are growing Technical Debt, because this will determine if we are taking too many shortcuts.”

Do some positive pruning

The more your product does, the more opportunity for technical debt to pile up. As a product manager, you’re lauded and rewarded for identifying new features and bringing them to market. But the opportunity to kill off dead-weight features is often ignored and these vestigial, little-used features suck up time and resources with every release.“Decide a ‘minimum bar of usage/value’ that every feature must pass in order for it to remain a feature. If a new feature doesn’t hit that bar in some set period of time, prune it,” says Dharmesh Shah of HubSpot. “Support those efforts to prune where pruning makes sense. Acknowledge that there will be some short-term pain, but that the long-term value is worth it.”You will inevitably face resistance from sales teams fearful of upsetting customers, but if it’s not delivering core value or being used that much, you should feel confident using the data to justify this hard decision.