Signs Worth Reading

We’ve all seen them: tickets in the backlog that just say “New onboarding flow.” Commits in source control that read “another fix.” Merge requests with the description box left empty. The scaffolding is there, but it doesn’t tell anyone what’s being built. It’s like driving past a road sign that only says “road.”

Whether the backlog lives in Jira, Linear or Notion, or the documentation sits in Confluence, and whether source control is GitHub, GitLab or Bitbucket, the pattern is the same.

These artefacts aren’t bureaucracy. They are the map and the markers that make product engineering visible. They connect the work of one squad to the intent of another. They tell the story of how a product came to be, not just the code that made it work.

And now, with AI in the picture, there is little reason for the map to be blank. An epic like “New onboarding flow” can be enriched with goals, edge cases and constraints without someone spending half a day writing them down. A commit that once said “another fix” can then be summarised in context. The link between backlog and source control creates the map. A map only works if the signs are clear enough to follow.

Maps without routes

Empty tickets and vague commits aren’t just a nuisance. They blur the outcome. Was the work meant to shorten the time from registration to first deposit? To reduce drop-off in certain states? To test a lighter design for mobile? Without that context, few will know.

And product managers rarely read the code. They live in the backlog. If the spec is vague, then even when the feature passes testing, it is hard to be sure it matches the intent. The signs exist, but they don’t point to the right place.

The same applies when conversations spill elsewhere. As I wrote in Shouting in the Digital Office, decisions shouted across a desk, dropped into a chat thread or hidden in a slide deck are lost to the mist of time. They leave no trace in the system of record. The real story begins in the backlog, and the output is in source control. When it lives elsewhere, the work may still get done, but the why is no longer obvious. The map is incomplete.

And there are reasons this happens. People move fast. Meetings run long. Context switches pile up. Writing things down feels like a delay, so teams default to the quickest channel. In the moment it works, but later the story is broken.

That isn’t saving time. It is losing not only the why, but the how.

Sat-nav for squads

When backlog and source control are stitched together properly, they behave like GPS. The “New onboarding flow” epic doesn’t just sit on a roadmap slide. It links directly to the commits that shaped it. Each commit carries its own roadside marker: a bridge rebuilt, a turn taken. Merge requests act like indicators, telling the convoy around you when a lane change is coming.

AI makes this far easier. Summaries can be drawn from diffs. Acceptance criteria can be inferred from logs, screenshots and reports. Even the vaguest “onboarding flow” commit can be expanded into a clearer description of what changed and why. The route map can update itself.

When the lanes converge

Clearer artefacts don’t just help engineers understand each other. They change the relationship between product and engineering.

Product managers who capture outcomes, constraints and success criteria with enough precision can go further than they might expect. With AI, those words can be translated into test scaffolds or early proofs of concept. A well-written epic can seed working code, allowing an idea to be explored before engineering commits to building the full road. In that sense, product begins to edge into engineering.

And the reverse holds too. Engineers who learn to express intent and player outcomes in writing start to edge into product. If you can frame a change in terms of a player journey, a conversion goal or a hypothesis to be tested, AI can carry it forward into the kind of artefact a product manager would create. Written clarity becomes a bridge.

This isn’t role erosion. It is the start of a deeper meld. Product and engineering remain distinct, but the flow between them becomes easier, faster and more experimental.

Arriving together

The story of a product should not be scattered across chats, slides, meetings or incidents. It should run straight from backlog into source control, with the signs along the way clear enough for anyone to follow.

The common thread through all of this is the written word. Expressing intent, outcomes and decisions in language that carries. Writing them down, in the system of record, is what turns an idea into a product.

And it is understandable why words leak into other places. Nobody skips documentation out of malice. They do it because they are under pressure, because the sprint is already moving, because it feels quicker to move on. But that short-term gain comes at the expense of long-term clarity.

Tools will evolve, and AI will continue to reduce the toil, but the enabler is still the same. Clear words, kept in the right place, are what turn work into product engineering. The rest is just clutter on the roadside.