The feature went out to the entire company as done.
It was the kind of announcement product managers live for. Leadership had been asking about this feature for a while — it was a big one — and now here it was on a slide, presented to everyone at once, wrapped in the confidence of a man who was genuinely excellent at presentations. Momentum. Applause. Next slide.
The ticket did say “done.” That part was true.
Some time later, someone from leadership went to actually use the feature. In production. Where users live.
It was not there.
Not broken. Not buggy. Not there. The feature the entire company had been told was delivered did not exist in any environment a user could reach — and the people discovering that were the exact audience the announcement had been made to.
Three people, three honest beliefs
The tempting version of this story has a villain who lied. Nobody lied. That is what makes it worth telling.
The engineer who built the feature moved the ticket to “done” — and by the engineer’s private definition, that was honest. The code was finished. It was merged. It was deployed and running in a pre-production test environment, where it worked. “My part is complete, and it runs somewhere” is a perfectly coherent thing for “done” to mean. It just is not what the rest of the company heard.
The PM read “done” and believed it meant “delivered.” That belief also was not crazy. What is a done status for, if not that? He was good at the front half of product work — the promising, the presenting, the momentum. The back half, verifying that a promised thing actually exists where users can touch it, was treated as beneath the role. So the status became a slide, and the slide became an announcement, with no verification step anywhere in between.
And leadership believed a company-wide announcement implied somebody had checked. Of course they did. That is what announcements are supposed to mean.
Three beliefs, all locally reasonable. No two of them referring to the same fact.
What the delivery evidence showed
Here is what the records actually said, at the moment of the announcement, to anyone who looked:
The tracker said done. The code host said merged. The deployment record said running — in a test environment no user could reach. The rollout state was not even a question anyone had asked. And production said: nothing here.
Five records, five different answers to “is it done?” — and every one of them honest inside its own boundary. The ticket was not lying about the engineer’s part being finished. The deploy log was not lying about where the code ran. Production was not lying about what users could do, which was: nothing.
The announcement had simply been sourced from the cheapest record in the chain, the one that carries the least information about reality. A ticket status is an assertion by one person about their own part of the work. It says nothing about environments unless something forces it to.
The part that still stings
Something could have forced it to.
The tracker and the code host had a built-in integration — the standard, boring, first-party kind — that links tickets to commits and deployments. Enable it, and every ticket quietly shows what code belongs to it and where that code is actually running. The gap between “done” and “done where?” becomes visible in one glance, to anyone, without asking an engineer a single question.
Enabling it was a few minutes of setup.
It was never enabled. Not because anyone decided against it — nobody decided anything, which is the point. It was not the PM’s priority, and it was never delegated to anyone either. Verification had no owner. And everybody knew — it was a running joke, the way it is on every team — that engineers are casual about ticket hygiene. The organization knew its statuses were unreliable, knew the link that would ground them in reality was minutes away, and announced a major feature to the whole company off a bare status anyway.
That is not one person’s failure. That is a system with a hole where verification should be, waiting for someone confident enough to fall in it publicly.
Who paid for it
The discovery could not have been staged worse. No release checklist caught it, no review caught it — the missing feature was discovered by leadership, hands on the product, in production, after being told it was delivered. Evidence that arrives that way does not read as a process gap. It reads as “we were told something false.”
The aftermath is where the story turns from embarrassing to instructive. The PM blamed everybody on the team except himself. The engineer — whose status had been true by their own definition — got to experience being the implied cause of a public miss. Trust inside the team was spent at the exact moment the team needed it. And some time later, the PM was let go.
Now, the uncomfortable question: what did the departure fix?
As far as I know, on the day he left, the integration was still not enabled. The verification step still had no owner. “Done” still meant five different things in five different systems, and announcements could still be sourced from the cheapest one. The organization had processed a systems failure as a people problem — the cast changed, and the stage stayed exactly as it was, ready for the next confident person to walk into the same hole.
I include myself in this, by the way. Everybody on that team knew the statuses were soft. Any of us could have spent the few minutes. We all had better things to do, right up until we very much did not.
How to see it coming
The public miss has quiet precursors. Any of these should make you nervous about the next announcement:
- Statuses change with no environment information attached — “done” without a where.
- Nobody can climb from a ticket to its commits to its deployments in one glance.
- Demos happen on test environments and nobody mentions the URL.
- “Deployed” is said in standups without naming the environment.
- Delivery announcements are prepared from the tracker, and verifying them is nobody’s listed job.
Each is survivable alone. Together, they mean your organization’s word “done” has quietly forked — and an announcement built on the cheapest version of it is a public incident on a delay timer.
The five answers to “Is it done?”
Here is the ladder I now insist on. Five records, five different questions, climbed in order:
1. Ticket
Did the assignee finish their part, by their own definition?
2. Repository
Is the change merged into the main line?
3. Deployment
Which environment is it actually running in?
4. Rollout
Is it enabled for real users, or dark behind a flag or a partial rollout?
5. Production
Has someone verified that a real user can do the thing, in production?
The rule that makes the ladder useful: status may be reported from any rung, but delivery may be announced only from rung five. “The ticket is done” is a fine thing to say in a standup. It is not a thing to put on a slide in front of the company, or in a client report, until the bottom rung answers yes.
And if the ladder cannot be climbed in one glance — if tickets, commits, deployments, and rollout state do not link to each other — then that link is the missing work item, and it is probably minutes of setup that has been nobody’s job for years.
The Scopeworth lesson
The expensive part of this story was never the feature. The feature was fine — it shipped to production eventually, like features do. The expensive part was that the organization’s delivery record could not answer “is it done?” with one trustworthy voice, so the loudest voice answered instead. When the record is silent, confidence fills the vacuum, and confidence does not version-control well.
Scopeworth is being built to turn fragmented delivery signals into client-ready evidence — connecting what was promised to what changed, what actually reached production, and what it cost, so a delivery claim can carry its receipts. It is early, and honest about that. But the principle is the one this story teaches:
“Done” is five different facts, and the only announcement worth making is one that can name its rung.
Your last delivery announcement — to a client, to leadership, to the company. Which rung was it sourced from? And could your team climb all five in one glance today?