When Building Features Becomes Too Cheap

We've heard it so many times that we almost stopped questioning it: more code doesn't mean more value. We believed it, tried to apply it, and eventually agreed with it. Some of us probably learned it the hard way, after delivering thousands of lines of code that nobody really cared about.

But here's another one: more features don't mean more value either.

Surprised?

Well, we shouldn't be. Still, I have a feeling that we are about to forget this simple principle. And, strangely enough, AI might be helping us do exactly that.

When building things was expensive

For a long time, delivering software features was expensive. Development teams had limited capacity, budgets were tight, and every new request had to compete with dozens of others.

As Product Owners or Product Managers, we had to make choices. Sometimes difficult ones. We had to understand the expected benefits, estimate the costs, discuss priorities, and eventually decide whether a feature was worth building.

Of course, this didn't mean we always made good decisions. Let's not pretend that software products were perfectly designed before AI came along. We delivered plenty of features that nobody needed. But the high cost of development forced us to think twice.

A feature that required three months of development needed a pretty convincing business case. Otherwise, getting it through prioritization was difficult.

And that was actually a good thing.

Development cost was acting as a filter. Maybe an imperfect one, but at least it forced us to ask an important question: Is this feature worth the investment?

And then AI came along

With AI becoming part of software development, things are changing. The cost of producing a line of code has dropped significantly in many situations. And with AI increasingly involved in analysis, design, development, testing, and documentation, the overall effort required to deliver certain features is getting smaller.

Of course, generating code and delivering production-ready software are two different things. We still need to validate, integrate, test, secure, and maintain whatever we build. But let's agree that, for many types of features, AI can make delivery considerably cheaper.

On paper, this sounds fantastic!

Finally, Product Owners and Product Managers can deliver more of what they propose. Features that used to sit in the backlog for months might now be implemented in days. That long list of nice-to-have features? Suddenly, it doesn't look so unrealistic. The software factory is becoming faster, and we can finally feed it all those ideas we have been collecting.

What could possibly go wrong?

The rabbit hole of cheap features

Here's where things become interesting.

Our traditional cost-benefit analysis follows a relatively simple principle: if the expected benefits justify the costs, the investment might be worth making. And when development costs go down, more features start looking like good investments. Something that wasn't worth building when it required three weeks of development might suddenly seem reasonable when it takes three days.

The problem?

The value of the feature hasn't changed. Only the cost of building it has.

The customer didn't suddenly develop a new need. The user didn't become more interested in using it. And the product didn't necessarily become better because we found a cheaper way to implement it. But now we can afford it.

So why not?

Well, because we can is a pretty poor reason to build something. We might end up delivering features that almost nobody wants, simply because we can. Even worse, we might convince ourselves that we're creating more value because we're delivering more features. The velocity looks great. The backlog is moving. Stakeholders are happy to see things getting done. Everyone is busy celebrating productivity.

Meanwhile, the customer might not notice any difference.

The feature nobody wanted is still there

Unfortunately, the story doesn't end when we release a feature.

Let's imagine we delivered something that looked like a good idea at the time. Six months later, almost nobody uses it.

No problem, right? We can hide it somewhere under three menus, stop promoting it, and move on. Except that the feature hasn't disappeared. It is still part of the product. It might need maintenance. It might break when we change something else. It might require additional testing, documentation updates, or security fixes. And when someone wants to redesign an existing flow, that forgotten feature suddenly becomes a dependency.

In AI-assisted development, unused functionality can even become part of the context we feed into our tools. Extra code and documentation that consume tokens and add unnecessary noise. We built the feature because it was cheap. Now we're paying to keep it alive. And we'll probably continue paying until someone decides to remove it.

Maybe we need to rethink what value means

I'm not suggesting that we should stop using cost-benefit analysis. Far from it. But as development becomes cheaper, the cost of building a feature should carry less weight in deciding whether that feature deserves to exist.

The fact that something is inexpensive doesn't automatically make it valuable. As product people, we need to become better at understanding the actual value of what we're delivering. And that means spending more time understanding the paying customer, the people who actually use the product, and, of course, the product itself. These are not always the same perspectives.

The customer might be paying for a business outcome, while the user is struggling with a complicated workflow. Adding another feature might satisfy a stakeholder request without improving either situation.

Sometimes the better decision is to improve what already exists.

Sometimes it's to simplify a process.

And sometimes the best decision is to do absolutely nothing.

I know. Not a particularly exciting thing to present during a sprint review. But probably a better outcome than adding another button nobody will ever click.

What about the features we already delivered?

There's another side of this discussion that I rarely see getting much attention in product conversations. We spend a lot of time deciding what to build next. We refine backlogs, prioritize initiatives, evaluate new opportunities, and argue about what should or shouldn't be included in the next release.

But how often do we seriously discuss what should be removed from the product? Not because it's broken. Not because we need to replace it. Simply because it no longer brings enough value to justify its existence. We've become quite comfortable with the idea of removing low-value items from the backlog. But once a feature is delivered, it somehow earns the right to stay forever. Why?

Maybe we should start considering the value of decommissioning features, alongside the value of introducing new ones.

That's a discussion worth having on its own. And one I'll come back to in a future post.

DeScope. Even after release.

AI is changing how we build software. And that's a good thing. We can experiment faster, validate ideas more easily, and spend less time and money turning good concepts into working products. But faster delivery doesn't guarantee better products. If we continue measuring success mainly through the number of features delivered, cheaper development might simply help us make more bad decisions, faster.

The Product Owner's role isn't to keep the software factory busy.

It's to make sure we're building something worth using.

And as the cost of building things decreases, knowing what not to build becomes even more important. Perhaps it's time to extend that thinking beyond the backlog.

DeScope the features you haven't built yet. But don't forget about the ones you've already released.

Maybe the next big improvement to your product isn't another feature. Maybe it's one less.

D. Scope