How to Stop the Feature Factory 🏭
Learning to balance your engineering investment.
Many engineering teams are terrible at prioritization.
We talk endlessly about moving fast, being agile, and creating customer value, but do not realize we are shooting themselves in the foot by trying to work on too many things at once.
In this article we focus on one way this problem can manifest: being stuck in building feature after feature. We explain why things will not improve if you just keep shipping more stuff.
Here is what we will cover:
🌡️ Symptoms of being stuck building new features — the most common tell-tale signs.
💸 The real cost of new features — the different types of work involved during the full life-cycle.
⚖️ Measuring the balance of engineering work — how you can measure where you spend your time, and why you should.
🏃♂️ Breaking out of bad habits — your best options to break the cycle and alleviate the root causes of your problems.
Let’s go!
🌡️ Symptoms of being stuck building new features
When it feels like your team isn’t getting anywhere, an important thing to understand is whether you are stuck in just building new features.
Here are the most common symptoms that tell you this is happening:
1) Lots of customer support 🗳️
Shipping new features often results in more customer problems to solve.
This happens because products are rarely ready in their first iterations — there are bugs to solve, things to add, and room for optimization.
If you always rush into building the next feature, these small imperfections will accumulate. You will face more bug reports and feature requests from customers, and you will eventually be overwhelmed by the volume of reactive work.
2) Lots of context switching 🔀
Chasing feature after feature can make developers exhausted from jumping between different topics, problems and abstractions.
Your team might find there are small corners to fix, improve and polish. In other words, the team is proactively addressing the symptoms before the surge of customer questions, and this is causing the context switching.
Ultimately, context switching reduces the team's capability to deliver new features:
It is stressful and eventually decreases team health.
It requires more coordination, because you have more balls in the air.
It increases the amount of prioritization and planning you need — taking time out of development.
It is not possible to focus on just one thing — but it is possible, even necessary, to focus on just a few things at once.
3) Difficult to start the next big thing 🪨
Teams that are overwhelmed with work find it difficult to reserve enough time for starting big initiatives.
The obvious reason is that there's too much going on already, and it's difficult to fit new projects among all the tiny tasks. It is like filling the glass with sand and then trying to fit in the big rocks.
Such a lack of focus creates a bias towards short-term work, and puts the team into a fire-fighting mentality. It might also create friction within the team, where developers resist starting new work because they feel there is too much to fix first.
4) Starting big things, but not finishing any 🏗️
Teams might be chasing too many big opportunities at once.
You may try to go after the most promising initiatives, but stakeholders might have competing priorities, causing the team to struggle finishing any meaningful work.
If you’re feeling any of these pains, I feel you! So let’s discuss the real cost of building new features 👇
💸 The real cost of new features
Focus requires constant effort.
In real life, teams are bombarded by requests to build new things, like requests from customers, the business, or any other source. It’s always difficult to say "no", so you may be tempted to find quick wins ("what can we do to close this customer?").
This is made worse by teams not understanding or communicating the full effort of new feature development. And that’s because:
Building new features isn’t just about building
While it can really take only two days to solve a problem on paper — like adding a button — a complete production version can take much longer because of non-functional work, like:
Designing for security and accessibility
Implementing automated tests
Figuring out potential bottlenecks at scale
Adding monitoring, logging, and general observability.
Then, to favor adoption, there is even more to do:
Figuring out how to get the feature to users
Writing docs (internal and external)
Communicating that the new feature exists
Instrumenting the feature with adoption tracking to measure its use
After releasing in production, the work doesn't stop and transforms into maintenance — like fixing bugs and making improvements customers are asking for.
This work only really stops if the feature/product is killed, or the company goes bankrupt.
While it may not seem plausible at first, the total lifetime cost of a feature might really be weeks or months of work, even for a simple one.
Each new feature adds up to the long tail of maintenance work — and this creeping cost is what eventually brings teams to their knees.
Maintenance costs are invisible
In the physical world — think factories, tangible products — it is obvious that there is a lot going on to support the production of things.
In software, a good part of it — think infrastructure, performance, and general maintenance work — tends to be invisible.
So, for tech leaders, being able to communicate the full cost of new engineering work is a superpower. Your best bet, for doing it, is by showing data 👇
⚖️ Measuring the balance of engineering work
Having hard data on what teams spend their time on can help them avoid the pitfall of just building new features. You can also use it to communicate where the time of your team goes, as a way to underline that quick wins are few and far between.
The best way to understand where the time is going is to look at the balance of engineering investments. Unless you already have a good way of doing this, I recommend starting with the "Balance Framework", which helps you understand the nature of the development work.
Engineering work is divided into two main areas:
🔴 Mandatory investments — to support running the business (keeping the lights on, KTLO).
🟢 Elective investments — which are something that can be prioritized.
The elective investments are further divided into three categories:
🔨 New things — work towards your business objectives, like new products, features, or integrations.
🔧 Improving things — improvements to existing features, including improvements in performance, reliability, and security.
⚙️ Productivity — improvements to engineering productivity. Internal tech can also help scale many company operations.
Categorizing all work helps teams have discussions based on data rather than just intuition, and it provides a tool for improving the balance between different types of work.
At its best, measuring balance can help teams prevent problems — simply by having visibility and by being able to show data to defend their priorities. But what if you’re already in trouble and want to get back on track?
🏃♂️ How to break out of bad habits
Teams that spend their time churning out feature after feature might see different symptoms, but there’s often one root cause: lack of focus.
This can’t be improved by just looking at how the team spends their time, because it’s a problem with prioritization and leadership.
Here are the best ways you can break the vicious cycle and get back on track 👇