Your Backlog Has the Same Problem Volkswagen Is Trying to Fix
Volkswagen is selling cars. Its revenue is basically flat. Automotive cash flow has improved by billions. Its new electric models have attracted more than 70,000 orders within weeks of launch.
And its CEO just told employees, in an internal memo obtained by Reuters, that “the situation is more than critical.”
How can both of those things be true at once?
Because Volkswagen isn’t really dealing with a sales problem. It’s dealing with the cost of everything it has accumulated over the years. If you own a Product Backlog, that should already sound a little familiar.
Global deliveries did fall, 6.3 percent in the first half of 2026, and almost all of that came from a 26 percent collapse in China. Outside China, the company’s own sales leadership says the group actually grew by about 2 percent. That context matters. But it’s not the number CEO Oliver Blume kept coming back to in his memo. He kept coming back to this one: Volkswagen’s overhead costs run more than 30 percent higher than comparable competitors. Not 30 percent higher revenue requirements, 30 percent higher just to run a business the same size as everyone else’s.
A company can have customers, stable revenue, improving cash flow, and a genuinely strong new product, and still have a competitiveness problem serious enough for its own CEO to call it more than critical. That’s the part worth sitting with for a second.
The number that explains the problem
Before the pandemic, Volkswagen built its factories to produce about 12 million vehicles a year. Today it’s producing closer to 10 million, delivering somewhere around 8 to 9 million, and management’s own target is to bring capacity down to 9. That’s a real shift, years of infrastructure, tooling, and organizational structure that got built for a scale the business simply doesn’t operate at anymore.
The response isn’t just “sell more” or “cut people.” It’s cutting the model lineup by up to half. Cut model variants and equipment options by up to 75 percent. One example the company itself likes to use: instead of offering over 2,300 seat variations, there will soon be about 100.
Sit with that number for a second. Two thousand three hundred versions of a seat. Nobody sat down one day and decided to build 2,300 of them. A regional team asked for one variant. A trim level needed its own version. A supplier offered another option, and somebody said yes because it seemed harmless. None of those individual calls looked wrong at the time, and that’s exactly how you end up, years later, unable to explain why most of them are still around.
Volkswagen’s problem isn’t that it makes bad cars, or that people stopped wanting them. It’s slower and less dramatic than that. For years, the company kept saying yes to another model variant, another trim level, another option package, another layer of approval, and at some point the cost of holding all of it together quietly grew past what the revenue could cover.
Nobody sat down one day and decided Volkswagen should cost 30 percent more to run than it needs to. It happened one reasonable-sounding addition at a time, over years, until the accumulated weight of all of it became the crisis Blume is now writing memos about.
Where this sounds familiar
If you manage a Product Backlog, you’ve watched a version of this play out at a much smaller scale.
Every backlog starts lean. Then, one sprint at a time, it fills up. A stakeholder asks for a small addition. A “quick” edge case gets added because someone hit it once. A feature nobody uses anymore stays in the product because pulling it out feels risky. An approval step gets added after one incident, and years after everyone’s forgotten the incident, the step is still there.
Every one of those decisions sounds reasonable in the moment. That’s exactly the trap.
Complexity rarely shows up as one bad decision. It shows up as hundreds of individually defensible ones, and the bill only comes due much later, when refinement sessions start taking twice as long as they should, when velocity quietly erodes, when nobody left on the team can explain why half the backlog exists.
A backlog doesn’t get expensive because someone adds one bad item. It gets expensive because nobody ever goes back and asks why the old ones are still sitting there.
The Complexity Tax
Here’s a distinction worth making precise, because “complexity is bad” is too vague to actually act on.
Every backlog item carries at least three separate costs.
The first is the cost to build it, development, design, testing, the obvious part everyone already accounts for.
The second is the cost to carry it. Refinement, prioritization, documentation, dependencies, ongoing maintenance, and just the mental overhead of remembering it’s there at all.
The third one is the one teams miss most. Once you build a feature, it doesn’t disappear. It becomes part of the product, something every future decision now has to account for, work around, or avoid breaking. Keeping a feature is also, quietly, a constraint on what you’re able to build next.
That third cost is the dangerous one because it compounds. Feature A interacts with feature B. B interacts with permissions. Permissions interact with reporting. Reporting interacts with an integration nobody quite remembers building. That small feature from two years ago usually isn’t small at all by the time someone finally has to touch it again.
In practice, the real cost of a feature has less to do with what it took to build and more to do with what it forces the team to keep thinking about afterward.
Volkswagen’s overhead didn’t come from one expensive model. It came from the accumulated weight of variants, options, and approval layers, none of them individually huge, none of them ever removed. Or in other words, the overhead comes from European bureaucracy.
The uncomfortable question
Try this one honestly, not as a rhetorical exercise.
If someone deleted 20 percent of your backlog tomorrow, how many people would actually notice?
Not “would someone complain.” People complain for all kinds of reasons that have nothing to do with value. The real question is whether a customer would lose something they actually experience and rely on day to day.
If your honest answer is “probably not much,” you don’t have a prioritization problem. You have a deletion problem.
And here’s the part underneath that’s a little harder to admit: deleting something often feels like admitting the original decision was wrong. So instead it just sits there, carried along indefinitely, because removing it would mean saying out loud that it probably shouldn’t have been added in the first place. Most Product Owners aren’t protecting old backlog items because the evidence still holds up. They’re protecting them because the evidence disappeared a long time ago and nobody wanted to be the one who pointed that out.
The “Would We Build It Today?” test
There’s a useful parallel in how Volkswagen approached its own cuts. The company is deliberately asking whether each model, variant, and option still earns the complexity it creates. That’s basically the same question worth asking of a backlog.
Pick one item that’s been sitting in yours for a while. Try to forget it’s been there for two years. Forget that someone important asked for it. Forget the story points someone already estimated for it back when it went in.
Then ask yourself: if this idea landed on your desk today, for the first time, would you actually choose to build it?
If the honest answer is no, the only thing keeping it around is a kind of privilege that old items get and new ones don’t. It already exists, so nobody has to justify it again. A new idea has to earn its place. An old one usually doesn’t have to, and that’s backwards. It’s also exactly how a backlog quietly turns into its own version of Volkswagen’s 30 percent overhead problem, without anyone ever deciding it should.
Somewhere past a certain point, this stops being refinement and starts being archaeology, digging through old tickets trying to reconstruct why someone, three years ago, thought this might matter. That’s not agility. That’s just organizational memory failing quietly.
A practical way to prune
For any backlog item that’s been sitting around without a clear justification, ask a few things:
- Who actually needs this?
- What measurable problem does it solve?
- What happens if we never build it?
- What is it costing us just to keep, in refinement time, maintenance, cognitive load?
- Would we choose it today?
If you can’t answer the first three of those clearly, that’s usually a sign you don’t have much of a case for keeping it.
None of this means complexity is always the wrong call. Sometimes it’s exactly right. A new feature might open up a real market. A compliance requirement might be non-negotiable. An architectural change might genuinely improve reliability. The question was never “can we simplify this.” It’s “does the value this creates justify the complexity it introduces.” Being able to build something isn’t the same as it being worth carrying. Volkswagen isn’t trying to become the smallest possible car company. It’s trying to become the one with the least unnecessary complexity for the value it actually delivers. That’s a reasonable standard for a backlog too.
If your backlog already looks like this
If you’re looking at your own backlog right now and recognizing years of “maybe someday” ideas, duplicate requests, forgotten features, and tickets nobody can fully explain anymore, that’s not something you fix with one good sprint. It’s exactly the pattern this whole article has been describing, and it usually takes a deliberate way of working through it rather than another round of gut-feel prioritization.
That’s the kind of decision-making the Scrum Career Accelerator is built to teach, 25 courses covering the full Product Owner and Scrum skill set, including a structured approach to exactly this kind of backlog cleanup.
Every addition creates a future obligation
Volkswagen’s lesson isn’t “build fewer cars.” It’s not even really “cut costs.” It’s that every model, every option, every approval layer, every backlog item feels small on the day it’s added. Years later, nobody experiences them one at a time anymore. They experience them as complexity.
That’s why good Product Owners don’t only ask what to build next. They also ask what’s still sitting in there that stopped earning its place a while ago.
Agility isn’t just about changing direction fast. It’s also about letting go of what’s slowing you down. And sometimes the most valuable thing you can put into a sprint isn’t another feature.
It’s the decision to finally stop carrying one.
