Escaping the Feature Factory

/A

Martijn Veldkamp

/A

December 10, 2025

We spent the last decade obsessing over speed. We adopted Agile, we SCRUMmed, did the DevOps, and we measured our success by velocity and deployment frequency.

For the most part, this was a necessary evolution. Business moves too fast for waterfall. Waterfall did have some benefits as well, but that maybe my age and only remembering the good times.

But in many large enterprises, the pendulum swung too far. We fragmentized the teams and optimized so heavily for the immediate delivery of new functionality that many departments turned into Feature Factories. We churn out tickets, we hit our Sprint goals, and we high-five at the demos.

Sprinting

But if you zoom out, you often see a troubling pattern. We are running faster, but we aren’t necessarily moving forward strategically. We are just adding more complexity on top of an already complex foundation. Because certain Teams have capacity, stuff get’s build that maybe shouldn’t/

As a Lead Architect, my biggest concern isn’t usually “can we build this feature?”. It’s “should we build this feature right now, what are the opportunity costs, and what is the long-term cost of support of that feature?”.

The Hidden Cost of “New”

The uncomfortable truth is that every line of code you write is a future liability. Every new application, every custom integration, and every clever workaround adds to the maintenance burden. Like a colleague of me wrote:

LEGACY does not care about your framework. LEGACY was here before you arrived. LEGACY will be here long after you leave. LEGACY has seen things. LEGACY does not discuss the things.

If your IT roadmap is 100% allocated to “new business innovation,” you are practically guaranteeing future stagnation. You are accruing technical debt at an unsustainable pace. Eventually, the sheer weight of the legacy estate becomes so heavy that your vaunted Agile velocity grinds to a halt. You can no longer move fast because you spend all your time keeping the lights on.

A strategic roadmap doesn’t just list what we are going to build. It lists what we are going to fix, simplify, and decommissions.

The Portfolio Mindset: Renovation vs. Innovation

To escape the Feature Factory, we have to stop treating the roadmap like a Sinterklaas wish list and start treating it like an investment portfolio.

In my approach to defining long-term strategy, I advocate for explicit “tax brackets” in the roadmap. We need to defend budget: in time, money, and cognitive load –> for Renovation. This isn’t just about rolling out improvements and patches. It’s about strategic modernization, some of my top of mind things:

Simplifying the landscape by killing (I’ve used the term nekschot) redundant applications Refactoring monolithic structures into manageable domains Investing in platforms that increase productivity

A healthy roadmap might be a 70/30 split between Innovation (new business value) and Renovation (architectural health). In times of heavy debt, that might need to shift to 50/50.

We all need to clearly articulate that skipping renovation today is borrowing against our agility tomorrow.

The Vendor Trap

This portfolio mindset must also extend to how you manage vendors.

In a complex domain, it’s tempting to solve a business need by quickly buying a shiny new SaaS point solution, like I don’t know a certain pricing platform. It’s fast, it’s easy, and the business is happy. But does it integrate, where doe it fit the long-term vision? Are we introducing another silo of data? Are we “leasing a car” for a commute when we should be investing in a public transport network or working from home?

Defining strategy means pushing back. It means demanding that we show not just a future feature roadmap, but how this will help us reach our goal, like simplify our landscape over the next five years, rather than just adding to the noise.

Modernization is a Habit, Not a Project

The key takeaway is this: You will never be “done” modernizing. It is not a project with a 2027 end date.

It is a continuous discipline.

The goal of a “post-agile” roadmap isn’t to stop delivering fast. It’s to ensure we can keep delivering fast for the next decade. That requires the discipline to balance the exciting work of the future with the necessary work of maintaining the foundation. You know the non-sexy groundwork that will keep the lights on.