Product managers have extensive knowledge and access to a company’s different departments and stakeholders. This makes them ideally placed to create a workplace culture around preventing and responding to technical debt. We offer some strategies that can help.
According to Gartner’s 2019 product manager survey, only 55% of all product launches take place on schedule. This is significant as product managers who typically launch on time are more likely to meet their internal targets within a year of launch. Of the 45% of product launches that are delayed, 20%, on average, fail to meet their internal targets.
Failure to launch in a scheduled time frame can be attributed to numerous factors, including lack of formal launch processes, delays in product development (bugs, errors, feature creep), failure to meet customer requirements, product quality, or even supply problems. Another reason is technical debt. Technical debt not only frustrates developers but causes a cascade of related issues: Unpatched errors mean unhappy customers. Customers leave negative product reviews leading to challenges for the marketing team. Unstable architecture delays new feature launches. Sales cycles are impacted. Senior management and investors are asking questions.
Product managers have a critical role in facilitating a product’s success: vision, features, strategy, product launch, market position and competitors, and road mapping. Their location at the crossroads between engineering, sales, support, and marketing means they are uniquely placed to address the problem of technical debt. Here are some actionable strategies that can help.
Your role should already include the cultivation of a strong relationship with technical leads and the CTO, and other department heads. Gartner’s survey found that 78% of product managers who viewed improving collaboration internally as one of their top three roles experienced low product failure rates. Take the time to talk regularly with tech leads and gain a shared understanding of the extent of technical debt within your company and a commitment to fixing it. Are there any champions within the development team (not necessarily in management) that would like to work on tech debt? Avoid making people feel blamed for technical debt. Instead, focus on the positives of what fixing debt will mean for your product, the company, and the customer. Encourage management to provide incentives for the reduction of technical debt such as a day off or a fun out of the office activity.
Bring Technical Debt out of the Shadows
Technical debt is ubiquitous and should be a part of every product meeting. Make it an actionable item and seek regular updates. To avoid appearing like a gatekeeper, strive to involve developers in problem-solving and set priorities for tackling technical debt. Do they prefer working in code sprints or blocking out a larger chunk of time? Who is responsible for what? How do the developers like to work: code sprints or a dedicated period to respond to technical debt. Who is responsible for what? What is everyone’s current workload? Are more staff needed (even temporarily)?
Ask the Hard Questions
Being a product manager is a constant battle of context-switching between tasks and timelines. You’re probably the best at it in the whole organization, with an ever seeing eye for all the facets of a project. Solving technical debt means strategy and commitment, but first, you need to ascertain the reality of the problem. Take an example like code errors, which are delaying a product launch. In an ideal world, your organization is tracking and monitoring technical debt with a progressive list of action items. If this is not the case, asking open questions can give you an honest and unflinching understanding of the extent of the problem, the potential consequences, and start a conversation for the way forward. Make a game of it; anyone who replies ‘it depends’ needs to put a dollar in a jar. Examples of what to ask:
- Are there strategic reasons for holding off on a solution (such as waiting for a technical upgrade on a particular piece of software used)?
- Are there technical debts that do not need fixing (such as an obsolete product offering)?
- How much work is required to fix this code?
- Can we commit to fixing this code later?
- Who will be responsible for any fixes and what is the timeline?
- Does this timeline conflict with other release plans, feature updates, etc.?
- What is the impact of not fixing this code on current customers and future versions?
- What needs to happen before we commit to future reworking or refactoring?
Embed Technical Debt Remediation Into Your Roadmap
Embed technical debt into your roadmap timelines. Allocate tasks and time to fixing bugs, code reviews, maintenance, and an overall reduction of the existing debt to build a stronger, more resilient product.
Make your roadmaps as open and visible as possible so that the developer team and other colleagues feel they are part of the product loop. Your roadmap should be fluid and changeable but also include some hard deadlines for responding to technical debt.
Remember that not everything needs refactoring, your goal is to identify the intersection of things you’ll work on this sprint, month, or quarter, and the parts of your codebase that have tech debt. Pay off the debt in that intersection, but not outside of it.
Make KPIs That Reference Technical Debt
Make the elimination of technical debt part of the means of tracking success within your organization. Create KPIs (key performance indicators) around product performance, and development velocity that specifically reference technical debt. If your company uses the Net Promoter Score (NPS) to measure customer loyalty, this could include feedback regarding delays in product fixes, bugs, etc. Sometimes getting feedback directly from the end-user really brings a problem home.
Consider How to Prevent Technical Debt
Explore with the tech leads what kinds of strategies can be incorporated into project processes to reduce technical debt. This could include mentoring, team training, and pair programming. Can these be included in product budgets? Identify skills gaps that place the responsibility for fixing code all on the shoulders of one person.
Be Scrupulous About Documentation
Some developer teams strive to create a culture of opportunistic refactoring where code fixes are done whenever and wherever code needs to be cleaned up – by whoever. While it sounds ideal, it’s less realistic in peak times with heavy workloads. Ensure your company documents debt and the responsibilities for cleaning it up. This should be a living document that is regularly referred to and acted upon. This is especially important in organizations as team members change.
author Cate Lawrence, @Cate_Lawrence