Most teams don't really notice when this starts to drift. It tends to happen slowly, through a growing backlog, a few planning sessions that feel productive, and a general sense that if work is being done, progress must be happening.
On the surface, ownership still looks clean. Engineers own the code. Product owns direction. Work moves through a system and ships.
In reality, the separation is less stable than that.
Code is easy to track. It changes visibly, can be reviewed, improved, and measured. It gives the reassuring sense that something is moving.
Product is less cooperative. It doesn't always move in response to effort, and sometimes it doesn't move at all, even when the system is shipping constantly.
That difference starts to shape behaviour over time. Teams gravitate towards what can be controlled. Backlogs become the centre of attention, and grooming becomes a way of staying aligned. Technical decisions feel safer to debate than product ones because they have clearer boundaries.
Delivery slowly starts to stand in for progress. It is not always stated directly, but it becomes easy to assume that shipping work is the same as moving the product forward.
At that point, ownership quietly shifts. Engineers end up owning the system that changes, while product ends up owning intent that may or may not still reflect what is being built.
The space between those two is where most assumptions settle.
You can see traces of this in approaches like The Lean Startup, where progress is framed around learning rather than output. When that loop weakens, output becomes an easier thing to measure than understanding.
In teams that maintain stronger discovery habits, that loop stays active. There's a useful framing of this in continuous discovery thinking, where product work is treated as ongoing adjustment rather than fixed planning.
But as organisations grow, that loop often stretches. Roadmaps become commitments, backlogs become inventories, and engineering becomes the place where decisions are executed rather than revisited.
You start to notice it in small ways. Features that are well built but slightly misaligned, conversations that focus more on implementation detail than whether the problem is still the right one, and work that feels complete without necessarily feeling correct.
None of this usually appears as failure. It appears as normality.
The system still ships. The code still improves. Everything looks like it is working.
But ownership has quietly drifted away from outcomes and towards artefacts, what gets built, what gets closed, what gets measured.
And once that shift happens, it becomes possible for teams to believe they are building products, even when they are mostly building code that resembles a product closely enough to avoid further questioning.
The gap is subtle. It rarely presents itself directly. It just accumulates.