A while back I wrote that shipping got faster and discovery didn't. That teams now build features faster than their users can find them.
That was true. It was also the small version of the story.
The bigger version is this: building software got automated, and everything after you ship it didn't. Not just discovery. Adoption, support, and fixes. The entire second half of a product's life is still done by hand, and the gap between the two halves is widening every week.
Every product has two halves
There's the half where you build and ship it. And there's the half where real people have to adopt it, get unstuck when it confuses them, and keep it working when it breaks.
AI coding tools collapsed the first half. What took months takes hours. DX measured it: teams using AI assistants ship about 60% more pull requests a week. A PM with an idea on Monday can have it in front of users by Wednesday.
The second half did not move an inch.
A human still has to notice a new feature exists, understand why it matters, and change a habit. When they get stuck, a human still writes the ticket, another human triages it, and a third eventually ships the fix. None of that got faster. Most of it didn't get touched.
So one half of your product now runs at machine speed and the other half runs at exactly the speed it did in 2015.
The bottleneck didn't disappear. It moved.
This is the part worth sitting with, because it's a law, not a coincidence.
When you speed up one stage of a system, you don't eliminate the constraint. You relocate it. Make the assembly line ten times faster and you haven't fixed the factory, you've just moved the pile-up to the shipping dock, the returns desk, and the repair shop downstream.
That's what happened here. We poured a decade of tooling into making "build and ship" fast. The constraint obediently moved to the place we built no tools for: everything after the ship. Pendo's 2024 benchmark, across 6,800 companies, puts average feature adoption at 6.4%. You can ship 60% more and have almost none of it land, because the landing was never the part that got automated.
The bottleneck has a new address. Most teams are still optimizing the old one.
The second half is three jobs nobody owns together
Here's why the after-half is so stubborn. It isn't one job. It's three, and they live in three different tools that don't talk to each other.
A user gets stuck. That's an adoption problem, and it sits in the product team's world. They file a ticket. Now it's a support problem, living in the helpdesk. The ticket turns out to be a real bug. Now it's an engineering problem, living in Linear or Jira.
Guidance, support, and tickets, three systems, three owners, and no thread connecting them. The user who was confused, the agent who answered, and the engineer who fixed it never share a single view of what actually happened.
So the work falls back on your team to stitch together by hand, every time. The PM owns the build. CS owns the tickets. Eng owns the bugs. The loop between them, the thing that would actually get a stuck user to an outcome and the bug to a fix, is owned by no one. It's nobody's job, which is why it's always the thing that's late.
And two forces are about to widen it
It gets harder from here, not easier.
Releases keep compressing. Quarterly became monthly became daily. Every release adds surface to adopt, support, and fix, with no extra hands to do any of it.
And your users are starting to change shape. More and more, people act through AI agents that operate your product for them. An agent hits the same dead ends a human does, but it can't read a tooltip, sit through a tour, or write you a thoughtful bug report. It needs a layer that can guide it and resolve what breaks in real time. UIs and help docs were built for humans, and they were already failing the humans.
What to do this week
Map your own second half. It's a whiteboard exercise, not a project.
Take the last time a user hit a wall in your product. Trace it. Who noticed. Who guided them, if anyone. Where the ticket went. Who caught that it was a bug. How long until it was fixed. How many separate tools that path crossed, and whose job the whole path was.
Count the tools. Count the owners. If the honest answer is "four tools and no single owner," you've found it. That's not an adoption problem, or a support problem, or a bug-triage problem. It's one post-production problem wearing three costumes, and no tool you bought was built to own the whole of it.
That's the gap we built Deway to close: one layer that owns the loop after you ship, guide, reroute, ticket, fix, for every user, human or agent. But you don't need us to run the map above.
Building became autonomous. The question every team should be asking this quarter is the obvious one nobody's funding.
If shipping now runs itself, why is everything after it still done by hand?
Alon Binman is the co-founder of Deway (deway.ai), an AI-native layer that runs everything after you ship. Before Deway, Alon spent 15+ years at the intersection of product and customer success, including roles as a Product Manager, founder, data and product strategy consultant, and Senior Solution Architect at Mixpanel. You can reach Alon on LinkedIn.