There's a slide in your roadmap review that has said "Beta" for fourteen months.
Nobody questions it anymore. It's just there, next to the Q3 goals that have quietly rolled into Q4 and then into a quarter that doesn't exist on the fiscal calendar but definitely exists in your sprint board.
Somewhere along the way, you stopped shipping things and started maintaining the appearance of shipping things.
How it starts
It starts honestly. A feature isn't quite ready. There's an edge case, a permissions bug, a migration that needs one more pass. Someone says the words that will haunt your backlog for the next year:
"Let's get it in front of users, we'll finish it next sprint."
That's a reasonable sentence. It's also a loan. And like most loans taken out by engineering teams, the interest is brutal and nobody's tracking the balance.
Next sprint comes. The team is on something else now — something with a deadline, something an exec mentioned in an all-hands. The beta feature is technically live. It has users. It has some users. Enough to justify not touching it. Not enough to justify investing in it.
So it sits. Half-built. Half-trusted. Fully load-bearing.
Why nobody finishes it
Because finishing work is invisible and starting work is celebrated.
Announcing a new feature gets you a Slack thread with 🎉 in it. Grinding through the last 15% — the error states, the docs, the tests that catch the thing that only happens when two users edit the same record at the same time — gets you nothing. It doesn't demo well. It doesn't go on a slide. It just makes the thing actually work, which is apparently the least interesting thing a feature can do.
Meanwhile, "beta" becomes a shield. Can't complain about the rough edges, it's in beta. Can't expect it to be reliable, it's in beta. Can't ask when it'll be done, because asking that makes you look like you don't understand how modern product development works.
Beta stopped being a technical status and became a political one. It's a way of shipping without committing. Of taking credit without taking responsibility.
What it actually costs you
Here's what a permanent-beta roadmap does to a team, and none of it shows up on a velocity chart:
Customers stop believing you. A beta label used to mean "this is early, tell us what's broken." Now it means "we reserve the right to abandon this." People plan around your software. They don't plan around things that might evaporate.
Your support queue fills with ghosts. Tickets for features that are "released" but not really. Bugs that get closed as "known limitation" because the limitation was never scoped out. Your support team is writing documentation for a product that's still arguing with itself.
New engineers can't tell what's real. They join, they see a codebase where half the features are behind flags, half the flags are stale, and nobody remembers which ones are safe to remove. They ask what the status of something is. They get three different answers from three different people. That's not a knowledge gap. That's an organization that has lost track of its own decisions.
And your roadmap becomes fiction. Not aspirational — fiction. You're planning next quarter on top of a foundation where a third of the "done" work isn't done. Every estimate is built on a lie you told yourselves eight months ago.
The test
Here's a question worth asking in your next planning meeting. Take any feature marked beta. Ask: what would have to be true for this to be not-beta?
If nobody can answer that in under a minute, you don't have a beta. You have a hostage situation.
If the answer is "we'd need to do X, Y, and Z" and X, Y, and Z have never appeared on a roadmap, then you've already decided — silently, collectively, without ever saying it out loud — that this feature will never be finished. You just haven't told the users yet.
The uncomfortable part
Permanent beta feels safe because it avoids the moment of commitment. But it's not safe. It's just a slower, more expensive way of failing. You pay for the feature, you pay for the support, you pay for the confusion, and you never get the one thing that actually compounds: trust.
So either finish it, or kill it. Both are fine. Both are honest.
What's not fine is a roadmap where everything is almost done and nothing is finished, and a team that's been telling itself "just one more sprint" for over a year.
That sprint isn't coming. It was never coming. You just stopped noticing you were waiting for it.
Top comments (0)