During my time in consulting and working across various companies, I’ve often noticed a disproportionate focus on product features. These are usually framed as the most important and urgent tasks, while other business priorities — such as technical maintenance, security, updating libraries and frameworks, or even internal tools that save employees time — are repeatedly postponed or marked as “for later.”
This is not exactly surprising. We don't concern ourselves with that which appears to be working — at least, not until it ceases to work. Let's look at this another way, though: consider an airline, for example. Its core product is moving humans from point A to point B reliably and as fast as possible.
When booking a flight, people are likely to focus on aspects like the ease of scheduling, cost of the ticket, company reputation, and in-flight experience — entertainment systems, food quality, ease of reserving, reward programs and other comforts.
Although airlines make efforts to improve these parameters, an important part of their business is safety features and routine maintenance of aircraft. On average, airlines spend between 9 and 15 percent of their revenue on keeping flights safe and planes operational. In part because they don't have much choice — transport authorities and regulators require complete compliance and transparent reporting. Within the digital product domain, some parallels, such as ISO/IEC 27001, SOC 2, HIPAA, etc., exist. Yet the question remains, how tightly are these followed, and are they robust enough to cover today's threats?
Many of the businesses I work with say they are concerned about delivery timelines ("we set deadlines, but it always takes longer") or the quality of the product ("customers are complaining the system is down or too slow"). For the most part, their product roadmaps have no work items related to performance, reliability, or security.
Why is that? Because it hurts to tell customers your product needs changes that have nothing to do with adding new features. Worse, if infrastructure changes are on a plan that customers have been shown, it may not be something to brag about. Let's say going to an airline's website and finding out their huge expense this year is an engine diagnostics system. Important? Yes. Exciting for customers? Probably not.
When I ask to see a roadmap, I generally follow this by asking: how many people do you have that you need to get this accomplished on time? The answer is always the same thing — literally the entire team. That makes work related to technical maintenance a low priority, often right to the point at which action is crucial. One client, for instance, had to shift a considerable number of their employees to overhaul their database system after learning that support for the legacy version would be ended in two months.
When we get in, it's pretty evident that engineering teams know about quality issues. Rapid feature development often leads to architectural issues and fragile systems. There’s usually a need to update dependencies, streamline development workflows, and introduce more modern tooling.
The longer you wait, the harder it gets. It takes time to add new capabilities because there is tangled or outdated code. The engineers must navigate technical minefields, and a single bug fix in a part tends to break things elsewhere. Legacy architecture also degrades product performance and scalability going forward.
Monitoring tends to be inadequate, which means the client is often the first to report an incident. Poor database encryption can lead to sensitive data leaks. These are all well-known problems — but the groups that have to fix them are normally full-up on feature work.
Even in new products, where the primary measure of user growth is crucial, reliability and security are just as significant as good UX or new design.
It's hard to imagine a legitimate corporation without an InfoSec division these days. And yet, year upon year, data breaches increase in quantity, with disastrous consequences.
When I speak with leadership teams about priorities, nearly everyone mentions product development — how to become more valuable to the customer or address their problems more effectively. Security and quality fall in second place or even third.
In practice, though, when we look at short-term roadmaps, it’s rare to find specific steps aimed at improving product quality, reducing technical debt (which often causes unpredictable outages), or strengthening system security.
In highly competitive markets, companies compete to offer the most feature-rich product. At the selection stage, customers usually care most about what a product can do. But after adoption, quality becomes the deciding factor in how long they’ll stick around — and whether they’ll recommend it.
- Features matter most at the start (“Does this product meet my needs?”)
- After adoption, quality takes over (“Can I trust this tool in real-world use?”)
- Enterprise clients, in particular, value reliability and are willing to pay for uptime, support, and long-term stability
It’s a bit like buying a car. You might choose one based on appearance or features, but if the quality disappoints, it’s unlikely you’ll buy from the same brand again.
Many leaders hesitate to advocate for technical improvements. It can be hard to explain the business value in clear terms. Product teams tend to find it easier to justify their proposals. But this mindset needs to change.
Here’s my key recommendation.
Companies should plan and manage technical initiatives — such as refactoring, architecture improvements, or security updates — just as seriously as customer-facing features.
Engineering leadership should maintain a clear, prioritised list of technical and security initiatives. Each initiative should include business impact, estimated effort, and what could go wrong if it’s deprioritised. This list should be reviewed regularly with leadership. Each initiative should have an owner — ideally a senior engineer or architect — who can lead the work if it gets prioritised.
Much like airlines, around 10–15 percent of available resources in every sprint should be consistently allocated to non-product tasks. These could include:
- Security improvements
- Performance optimisation
- Incident analysis
- Removing sensitive data from logs
- Enhancing test coverage and documentation
- Improving monitoring and observability
This technical backlog should be updated quarterly. Priorities and deadlines can shift, and new items can be added or removed as needed.
The company’s CEO and leadership team should have visibility into this registry. Ideally, it should be part of the monthly leadership meeting agenda, where the most critical initiatives are reviewed. Given that resources are always limited, the key is to consistently deliver the highest-priority improvements — sprint after sprint.