A frequent point of debate between product managers and technology development teams focuses on the allocation of time between developing new features and maintaining existing products. Development time, particularly in startups, is a limited resource that depends heavily on team size and must be carefully managed and allocated. In this post, we explore a framework for approaching this challenge.

New features often generate excitement, drive growth, enhance products, and attract considerable attention. In contrast, maintenance, or addressing technical debt, tends to be viewed as less glamorous, not directly contributing to new capabilities, and often regarded as a tedious necessity. Much like many things in the world, software requires upkeep. Although not literally true, I frequently liken software to a living entity that requires care and attention.

Even without the introduction of new features, software naturally degrades over time. Emerging security vulnerabilities, minor bugs, memory leaks, and other issues can compromise application stability, necessitating maintenance efforts. 

I once met a Ph.D. computer science researcher who posited that predicting code errors was as simple as examining code deployment frequency. The more code you produce, the more issues arise. While this may seem obvious, the underlying truth is that any interaction with your application can introduce problems.

Technical debt has become such a widely recognized issue that mainstream publications like the Wall Street Journal have discussed it, describing it as "The Invisible $1.52 Trillion Problem: Clunky Old Software." Technical debt refers to the future cost incurred by opting for an easy, quick, or limited solution now instead of a more comprehensive approach that would require more time. Similar to financial debt, technical debt accrues interest, meaning the longer it goes unaddressed, the more it can impede future development by making the codebase increasingly challenging and time-consuming to modify or extend.

Various factors, including rushed releases, a poor understanding of requirements, inadequate testing, or the use of outdated technologies, can contribute to technical debt. Effectively managing technical debt is vital for the long-term health, scalability, and maintainability of a software project.

In extreme cases, as highlighted by the WSJ and often discussed at Bankrate, the accumulation of technical debt may necessitate declaring "technical bankruptcy" and starting anew with a complete rewrite, significantly disrupting the development of new features.

Given the significant impact of technical debt, it's crucial to thoughtfully allocate development time. Product managers (PMs) might initially expect 100% of a developer's time, equivalent to 40 hours per week, to be available for new features. However, this approach can be a recipe for disaster.

Instead, I advocate for teams to plan for only 50-60% of a standard workweek to be dedicated to new feature development and functionality work.

Additionally, 15-25% of each week should be reserved for maintenance, refactoring, and addressing technical debt. The remaining 15-25% should be allocated for overhead tasks such as training, company meetings, primary research, and development.

Balancing the demands of developing new features with maintaining existing products relies not just on how we allocate our time but also on our ability to make and refine accurate estimates. A common pitfall for many teams, especially in startups, is either underestimating the complexity of tasks or overestimating their team's capacity. Estimating incorrectly leads to scenarios where teams are unwittingly setting themselves up for failure, working unsustainable hours, or, conversely, not completing planned work due to optimistic scheduling.

Accurate estimations are essential to avoiding burnout and frustration. We can better manage the delicate balance between innovation and maintenance by initially setting realistic expectations and then continuously refining these estimates based on actual performance and outcomes.

The iterative process of estimation and adjustment allows teams to become better at forecasting their capabilities over time. It's a learning curve that requires patience, persistence, and a willingness to adapt. By doing so, we not only honor our commitment to deliver high-quality products but also respect the well-being of our team. It’s about creating a sustainable development rhythm that accommodates growth, innovation, and the inevitable unpredictability of software development without falling into the trap of overcommitment.

By entering sprint planning with a balanced approach to time allocation, product managers can more effectively produce high-quality products quickly because they are:

• Making more reliable plans by accurately accounting for the time required for new features
• Investing in stability because while new features may attract users, instability can drive them away
• Providing developers with opportunities for training, growth, and innovation
• Showing respect for the solution development process

While we admire companies known for their rapid delivery, speed in shipping does not come from overloading sprints or overworking developers.

I serve as an advisor to a company undertaking similar initiatives to those I pursued at Wallaby. The founder once remarked, "Wow, you accomplished so much at Wallaby in such a short time with so few people."

Indeed, our team was small, comprised of one mobile engineer, one services engineer, one backend engineer (who also served as the CTO), one data/DevOps engineer, and one user experience designer, with occasional support from a contract web engineer. Our achievements, including launching mobile applications on Apple and Android, a web application, a Chrome extension, and more, were not the result of working 90-hour weeks. Rather, they were due to having clear objectives, valuing time off, and committing each sprint to maintenance.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.