The PM who reads the diff
Reading code is not a party trick for product managers. It changes which arguments you are able to have, and how early.
Before I owned a roadmap I was a fullstack developer, and then a Tech Lead at a media company in Seoul with eight people and a set of data platforms to keep alive. Moving into product changed the surface I work on, not the tools. I still pull the branch. I still open the diff on a ticket I wrote.
Not to review it. Reviewing is somebody else's job and they are better at it. I open it to find out whether what we agreed in planning is what is being built.
Most weeks it is. That is the boring and correct outcome, and it is worth saying out loud, because the case for a PM reading code is usually made with a heroic story where the PM spots the bug. That is not the value. The value is that a plan stops being a paragraph and becomes something with a shape you can check.
Which arguments become available
The arguments a PM can have without reading code are mostly about priority and scope. Should we do this now, how much of it, who is it for. Those arguments are real, and you can run a whole career on them.
Reading the diff adds a second set. Whether the thing we described is actually the thing in the codebase. Whether the seam we drew on the whiteboard exists anywhere in the implementation, or whether two components we keep talking about as separate are in fact one function with a flag. Whether the "small follow-up" we deferred last month is small, or whether it was deferred because it is not small and nobody wanted to say so in the meeting.
That last one is the most useful and the least comfortable. Estimates are social. A number given in a room full of people carries whatever pressure is in the room. The code does not care who is in the room. When I look at where a change has to land and how many call sites move with it, I am not checking the engineer's honesty. I am removing the need for them to argue against the room on their own.
True Platform runs on an AI-native architecture with seven specialised agents, and new trial activation went from 4% to 30% while we rebuilt it. A lot of that work was boundaries: what each agent is responsible for, what it hands off, where a user falls through the gap between two of them. Those boundaries live in code. You can draw them in a document and be wrong for a quarter.
The other thing that changes is timing. A bad plan caught in planning costs a conversation. Caught at code review it costs a few days and some goodwill. Caught after release it costs the release, and on a weekly cadence with an A/B loop running, a wasted release is a wasted week of learning, not just a wasted week of building. Reading the diff moves detection earlier by roughly one step. That is all. One step is a lot when you ship every week.
What it costs
Two failure modes, and I have been in both.
The first is doing the engineer's job. It starts as a question and ends as a suggestion about implementation, and once a PM starts suggesting implementations the team quietly stops making decisions in front of them. You lose the thing you actually needed, which is engineers arguing with each other about the design while you listen. I have caught myself drafting a comment about how something should be structured and deleted it. The test I use is whether the comment is about what the software does for a user or about how the code is arranged. The second kind is not mine to make.
The second is reviewing style instead of substance. Naming, file layout, a pattern I happen to prefer from my own repositories. It feels like contribution and it is noise. Worse, it trains the team to read my comments as taste rather than as product signal, so the one time I have something load-bearing to say it lands with the same weight as an opinion about a variable name.
There is a time cost too. It comes out of the same hours as customer calls and enterprise escalations, and the escalations are where two million in ARR came from on TestCloud, so it is not free.
I keep doing it because of what happens to my own planning. I run product on gh-roadmap, a tool I wrote that keeps a roadmap in GitHub issues with two-way sync, so the planning artefact and the work live in the same place. When the roadmap and the repository are one click apart, a vague item is obvious. You cannot write "improve onboarding" next to a list of commits and feel good about it.
Most weeks the diff tells me nothing I did not know. I read it anyway. The weeks it does tell me something, it tells me before the release rather than after.