Shipped means something more.

Every product organization I have been inside celebrates "shipping" in roughly the same way. There is a Slack channel. There is a rocket emoji. There is a line in the all-hands deck about what shipped this quarter. The list of shipped features is what the head of product reads to the board. And in nearly every one of those celebrations, at least one item on the list is not actually shipped. It is deployed.

The distinction is structural, not pedantic. I have watched a feature get the rocket emoji on a Friday, sit unused over the weekend, and never make it onto a customer's screen in any meaningful way. The release notes mentioned it. The marketing email did not. The PM moved to the next thing. Six months later, the feature is technically in the codebase, technically reachable through a UI flag the customer was never told about, and technically counted as "shipped" in the product roadmap retrospective.

It was deployed. It was not shipped.

The classical product-development model is the Double Diamond: discover, then deliver. Each phase splits into a diverge-and-converge cycle — in discovery, the team widens to explore the problem space and narrows to a clear bet; in delivery, the team widens to build options and narrows to a working product that reaches the user. Shipping was the moment the second diamond closed.

What has changed in the last few years is the cost of building. AI has compressed the delivery diamond so aggressively that building is no longer the slow, expensive phase it used to be. A team can prototype, iterate, and re-prototype while still inside discovery. Building has gotten cheap.

That does not absolve a team from the part of shipping that AI did not compress. The feature still has to reach the user. The user still has to find it, try it, keep using it. Telemetry still has to fire. Feedback still has to come back. The release cycle still has to close. Eric Ries called the same thing validated learning in 2011 — the only output of product work that actually counts. Marty Cagan called the build that nobody used delivered but not adopted in Inspired. Charity Majors at Honeycomb has been writing about production is where you find out for the better part of a decade. None of this vocabulary is new. It is vocabulary the product industry forgot when continuous deployment made the first quarter so cheap that the rest of the loop fell out of view.

Part of the reason product and engineering organizations anchor so hard on DORA metrics — deployment frequency, lead time for changes, change failure rate, mean time to restore — is that they are objective and unambiguous. How many deploys did the team push today? Easy to answer. Was anything that shipped actually used by anyone? That feels subjective. Different people will give different answers. So the conversation defaults to what is measurable.

The DORA framework, codified by Nicole Forsgren and the Accelerate research, has done real work raising the floor on how teams operate. But it measures the first quarter of the work — the part that AI compressed. The half of shipping it does not measure is the half that decides whether the work mattered. Adoption rate. Activation per cohort. Retention curve. Feedback loop closure time. Those dashboards are usually owned by a different team — product, growth, customer success — and they are usually disconnected from the engineering dashboards that track deployment. The two halves of shipping live in two different rooms, and the easy-to-measure half always wins the conversation.

When does a feature count as shipped? The honest answer is that it depends on the bet. Some possible goal lines:

• When the first user has tried it and given feedback.
• When a target group of users is using it repeatedly, without the team prompting them.
• When the feature has hit a hundred users, a stated activation rate, or first revenue.
• When a target cohort retains on it for two cycles in a row.

Different bets call for different lines. The discipline is not picking the "right" one. The discipline is picking it before the build, so the team knows what it is converging toward inside the delivery diamond. If the target is just "code in production," the team has implicitly defined shipping as deployment. If the target is "a hundred active users in eight weeks," the team has implicitly defined shipping as the full loop closing.

Every defensible goal line shares the same three components: the user received it, the user tried it, feedback came back. Validation comes from one of three sources — repetitive use, willingness to pay for the software, or positive references to other potential users. Anything short of those signals is a deployment, not a ship.

The term AI slop has organic adoption now. It started on the consumer-content side — AI-generated articles, images, and posts that bypassed quality review and flooded the open web with output nobody bothered to validate. The phrase migrated into engineering and product vocabulary in the last year because the same dynamic shows up at the product level: code generated faster than the team can validate it; features deployed without discovery, telemetry, an experimentation plan, or a launch motion; output that exists in production but has no answer to the question of whether anyone wanted it.

AI slop, in either form, is a quality-of-loop problem rather than a quality-of-output problem. The code is often good. The image is often beautiful. The article reads well at the sentence level. What is missing is the validation that what was produced was wanted, by whom, and whether it works. More deploying without shipping is exactly the dynamic that produces more slop. The counter is not slowing the deploys down. The counter is shipping more — closing the loop on the work that already left the editor.

Look at the dashboard your team uses to mark something as shipped. If it updates the day the code goes to production — if the rocket emoji fires when the deploy completes — the dashboard has defined shipping as deployment. That is a choice. It does not have to be the choice.

The question is not whether your engineers shipped faster this quarter. They probably did. The question is what your team's goal line for shipped actually is — and whether you set it before the build, or after.