YAGNI: Why 64% of the Features You Build Go Unused

Think of a feature your team shipped that nobody uses. You have one. Everybody has one.

Now try to remember what made it look necessary at the time. Usually it is not stupidity or bad process. It is a reasonable-sounding request from a credible person, arriving in a meeting where nobody could say out loud what it would cost, so it went on the list. Then it got built, tested, documented, and maintained, and it sits there quietly costing money every release.

According to Scrum Inc., 64% of features developed are not used by customers. Nearly two thirds of the work — built, tested, maintained, paid for — is doing nothing. If that number is even directionally right for your team, it is the largest single line item in your budget, and it does not appear on any budget.

YAGNI is the principle that keeps it honest: ya ain't gonna need it. Build the features you need, not the features you can imagine.

Nearly two thirds is not a rounding error

Take the number seriously for a minute before you argue with it. If 64% of what you build goes unused, then for every three engineers you employ, roughly two are producing inventory. Not bad work. Not slow work. Careful, well-tested work that no customer ever touches.

And the cost does not stop at the build. Every unused feature is a thing to keep working through framework upgrades, a thing to regression-test, a thing that shows up in a security review, a thing that makes the next feature harder to add because it is in the way. You pay for it once to create it and then a small amount forever.

The reason this is worth naming precisely is that most improvement efforts aim at the wrong target. Teams work hard on delivering faster. Delivering the unused 64% faster is not an improvement.

Why smart people keep doing this

Two reasons, and neither is a character flaw.

The first is fear. When we list requirements, most of us list everything we can possibly think of rather than what we truly need — because if I do not ask for it now, I may not get another chance. Everyone who has lived through an annual planning cycle has learned that lesson honestly. The behavior is rational inside a system where asking is free and asking later is impossible.

The second is that most people cannot equate time to money. We ask for things as though they arrive from a warehouse. There is no felt sense that a request is a claim on weeks of a team's life, and no visible opportunity cost — the thing that could have been built instead, with the same weeks, for the same money.

Put those together and you get the age-old problem of software development: separating want from need. It is not solved by asking harder. People genuinely believe they need what they want, and interrogating them about it just makes the conversation adversarial while producing the same list.

YAGNI is enforced structurally, not by asking harder

The fix is not a better question. It is a picture that makes cost visible at the moment of asking.

This is why YAGNI and story mapping belong together. On a story map with a release line drawn across it, everything above the line is a commitment and everything below it is a candidate. If a stakeholder wants a feature above the line, something else has to move below it. The trade stops being theoretical.

That turns "could we also…" into "instead of what?" — which is the only version of that conversation that produces good decisions. Notice what it does not do: it does not say no. It does not require you to out-argue a senior person, and it does not make you the department of no. It makes the trade visible and lets the person asking see it for themselves.

I watched a product owner replace her prioritization spreadsheet with two artifacts: a map with a release line, and a one-line value statement for each above-the-line story naming the outcome and how it would be checked in ninety days. The following quarter, two of an executive's requests came off the line — not because she blocked them, but because he read the trade himself and moved them. Nothing was won by arguing. The information was simply in the room.

Run every request past three perspectives

Before something goes above the line, it should survive three questions. They belong to the three perspectives that any product decision needs and almost nobody has all of:

Perspective	The question it owns	What a weak answer sounds like
Customer	Which persona needs this, and what can they not do today without it?	"Customers have been asking for it" — with no persona and no journey step
Business	What outcome does this produce, and how would we know it worked?	"It's strategic" — with no measure and no owner
Technology	What does this cost, and what does it make harder later?	"It shouldn't be too bad" — with nobody having looked

If one of those perspectives is not in the room, name the gap out loud — "we are deciding this without anyone who has talked to a customer" — and record the decision as provisional. Saying it is often enough to change the outcome.

The value filter: transparent, clear, explicit, testable

The word value gets used constantly and defined rarely, which is how it ends up meaning "the thing I want." Value is an exchange: a benefit given in return for a product or service. Features are the means; value is the end. A feature that produces no benefit for anybody is cost with no value attached, and 64% of features are exactly that.

For decisions to hold up, a value claim has to pass four tests:

• Transparent — everyone can see the reasoning, not just the conclusion.
• Clear — it can be stated without hedging.
• Explicit — it is written down rather than assumed.
• Testable — someone could check afterward whether it actually happened.

A value claim that fails those four tests is an opinion, and opinions get resolved by seniority. That is the real mechanism behind most bad roadmaps: not bad intent, just an absence of anything in the room that is not an opinion. Many organizations decide what to do next by who is screaming the loudest, and the customer — who is not in the room — loses every argument they were never allowed to make.

Write one value statement per story above your release line: the benefit, the person who receives it, and the signal you would expect within ninety days. Then actually look, ninety days later. Checking the decisions you already made is the fastest way to get better at making them.

Do not let this become a war on soft value

Two cautions, because YAGNI in the wrong hands does real damage.

First, intangible value is still value. Customer goodwill, brand, employee trust, the feeling of not being abandoned when something goes wrong — none of it lands on a spreadsheet, and treating only the measurable kind as real quietly ranks trust at zero. The discipline is not to price the unpriceable. It is to name what you would expect to observe if the intangible value were real, and then look for it.

Second, do not build a scoring machine. Value filtering does not need a weighted formula with eleven criteria. Elaborate models create false precision and become a way to launder opinion through arithmetic. Name the benefit, name the person who gets it, name how you would know, and compare honestly. That is the whole method.

The goal is not to win the argument about the four features somebody wants. Some of them will survive the filter, and they should. The goal is a decision your team can explain in six weeks when somebody asks why — which is a much better standard than being right, and a far more achievable one.

Key takeaways

• Scrum Inc. reports 64% of developed features are never used — the largest line item that appears on no budget.
• Teams over-ask out of fear and because a request never feels like a claim on weeks of someone's life.
• YAGNI is enforced structurally, not by asking harder: a release line turns "could we also" into "instead of what?"
• Value has to be transparent, clear, explicit, and testable — anything less is an opinion, and opinions get settled by seniority.
• Intangible value is real value; name the signal you would expect to see rather than pricing the unpriceable.

Frequently asked questions

What does YAGNI mean?

YAGNI stands for "ya ain't gonna need it." It is the principle that a team should build only what is needed now, not what might be needed later. It originated in extreme programming as advice about code, and applies just as directly to product scope: features built for imagined future need are paid for immediately and used rarely.

What percentage of software features go unused?

Scrum Inc. reports that 64% of developed features are not used by customers. The cost is not only the original build — every unused feature must be maintained through upgrades, regression-tested, reviewed for security, and worked around when the next feature arrives. It is paid for once to create and then a small amount forever.

How do you tell the difference between what a stakeholder wants and what they need?

Not by asking harder — people genuinely believe they need what they want. Make the cost visible instead. On a story map with a release line, adding something above the line visibly pushes something else below it, which converts the request into a trade the asker can evaluate themselves. Structure resolves this argument; interrogation does not.

What is a value filter?

A value filter is the deliberate evaluation that decides which product options are worth building. It requires each value claim to be transparent (the reasoning is visible), clear (statable without hedging), explicit (written down), and testable (checkable afterward). A claim that fails those four tests is an opinion, and opinions get resolved by seniority rather than by evidence.

What is the difference between tangible and intangible value?

Tangible value can be counted — additional revenue, cost reduction, a larger customer base, avoided penalties. Intangible value cannot: customer goodwill, brand, reputation, employee trust. Both are legitimate. The mistake is treating only the measurable kind as real, which systematically under-invests in trust. For intangible value, name the observable signal you would expect even if you cannot price it.

Making the trade visible

Module 2 of my User Story Mapping class puts YAGNI and the value filter to work on a real product — three perspectives, seven product dimensions, and a first release you can actually defend.

See the class