Main idea

A capability gap is opening between Product Managers from a technical background and the others. It bears neither on the understanding of the market, nor on the quality of judgment, nor on the ability to name a problem — the grounds where the job is usually played out.

It bears on access. Someone who can read a repository, follow merge requests and query a commit history can work directly on the product's material: generate an artifact from it, check that a document tells the truth, contradict a claim by showing the code. Someone who cannot has to go through another person, and the round trip costs enough that they give up in most cases.

The gap is therefore a gap in tooling, not in worth. That distinction matters, because the two call for opposite remedies: an aptitude deficit is recruited for, an access deficit is learned or tooled.

Layer added by "PM, Developers, and AI: Roles Are Blurring, Responsibilities Remain" (2026-08-01). The access gap widens further when the Product Manager starts building. Reading a repository, understanding an error, holding a dialogue with a code agent, spotting an absurdity in what was generated and asking for the right technical review condition everything that goes beyond the mockup: as long as the tools remain fallible, you cannot ignore what happens under the hood. The boundary is dated, and it can flip — if agents become markedly more reliable, profiles from psychology, literature, design or research would regain the advantage through their ability to finely express a human and business reality.

Why it matters

It avoids the identity reading — "technical PMs are better" — which closes the discussion, and replaces it with a workable question: what access does a non-technical PM need, and at what price can they acquire it?

It also says what happens if nothing is done: the gap does not close on its own, because it compounds. Every check made directly refines the understanding of the product, which makes the next check faster.

Nuances and limits

Access is not an advantage without a downside: the technical PM can start handling the problems they know how to solve with code, at the expense of those that belong to the market.

And the boundary moves. Tools that make a repository queryable in natural language lower the cost of access without removing it — technical literacy remains necessary to know what to ask and to judge the answer.

Open questions

• What form of learning gives a non-technical PM the useful access without turning them into a developer?