A question that is almost always framed wrong
"Do you need to code?" assumes a binary answer to a continuous reality. Between a Product Manager who has never heard of a token and one who ships prototypes to production, there are a dozen intermediate positions, and most roles sit somewhere in the middle. The useful question is different: how much understanding does it take to make good product decisions about a system whose behaviour is not deterministic?
That shift matters. On a conventional product, a PM can reason in rules: this action opens that screen, this calculation returns that number. On an AI product, the system produces a distribution of behaviours. Two similar phrasings return different answers; the same phrasing can be excellent on one case and poor on the next. Scope, guardrails and measurement then become product decisions in their own right — and they are made in a vocabulary the PM has to own.
Coding is one skill. Understanding a probabilistic system, its data and its failure modes is another. They overlap partially, but it is the second one that determines the quality of product decisions.
Level 1 — non-negotiable, even without writing code
This foundation holds in every context. It is not about knowing how a model is trained; it is about knowing what it does, what it does not do, and what failure looks like.
What the system can and cannot do
- Behaviour is probabilistic: the same input can produce different outputs, and a plausible answer is not a verified answer.
- A language model works on the context it is given; what is not in the context does not exist for it, except as training memory with no freshness guarantee.
- Hallucinations are not a one-off bug waiting to be fixed: they are the flip side of a system that produces plausible text. You reduce and contain them; you do not remove them by management decision.
- Quality depends first on the data you can reach: coverage, freshness, access rights, structure.
- Without evaluation, no claim about quality means anything. "It works well" is not a result.
Constraints that turn into product trade-offs
- Latency: a system answering in several seconds does not fit the same journeys as one answering instantly. That is an experience decision, not an implementation detail.
- Cost: every call has a price that varies with context length and model choice. A feature can be excellent and economically unsustainable at real volume.
- Privacy and rights: what leaves the organisation, what is retained, what a given user is allowed to see through the assistant. An assistant must never widen the permissions of the person using it.
- Prototype limits: a demo proves a behaviour is possible on chosen cases. It says nothing about stability on unchosen ones, nor about cost, nor about maintainability.
A PM who owns this level already makes better calls than many more technical profiles: they know when an idea is unworkable within the product's constraints, and they know why.
Level 2 — highly useful: being able to check things yourself
The second level is still not about writing production code. It is about shortening the loop between a hypothesis and an observation. A PM who can test a hunch in an hour does not spend an engineer's time settling a coarse feasibility question — and shows up to the conversation with observations rather than opinions.
- Testing a hypothesis quickly: run twenty real cases through the system and look at what breaks, instead of reasoning from three flattering examples.
- Understanding what an API is: what you send, what you get back, what a call costs, what happens on error or quota overrun.
- Reading technical documentation without flinching: context limits, output formats, configuration options.
- Handling a prototyping tool — a connected spreadsheet, a prompt workbench, a no-code builder, a shared notebook — well enough to produce something usable.
- Understanding the general shape of a workflow: a plain call, retrieval then generation, or a chain of tool-using actions. Knowing what is being discussed is enough; implementing it is not required.
- Talking precisely with Engineering and Data: naming objects correctly, telling a retrieval problem from a phrasing problem, asking a question that does not force the other person to rewrite the request first.
This level has a clear side effect: credibility. An engineering team pays different attention to someone who has already looked at the data and tested the behaviour before opening the discussion.
Level 3 — writing code: a context-dependent bonus
Being able to write some Python or JavaScript, call an API, assemble a small prototype: that is a genuine advantage, and it would be dishonest to downplay it. But it is a contextual advantage, not an entry ticket. It weighs heavily in some setups and almost nothing in others.
- Startup or very young product: nobody is free to validate a hunch, and a self-sufficient PM saves weeks.
- Small team: role boundaries are blurred by necessity, and technical contribution widens what the team can explore.
- Intensive discovery phase: when the open question is what the model can actually do, direct experimentation usually beats a specification.
- Deeply technical product sold to developers or data teams: credibility with those users comes from first-hand understanding.
Conversely, in an organisation with an established AI Engineering team, a full backlog and serious compliance or coordination stakes, the marginal value of a PM who codes is small next to the value of a PM who frames, prioritises and arbitrates well. Reading a universal hierarchy into this is an analytical mistake.
Scenario: two Product Managers, two outcomes
A deliberately simplified teaching scenario. A company wants to help its advisors find information inside a large internal documentation set. Two PMs approach it differently.
The PM who codes but frames badly
They build a convincing prototype themselves within days, pick a technical approach and present it as the solution. Nobody has established which questions advisors actually ask, or what happens when the documentation is ambiguous or out of date. The prototype ships; real usage stays low, because advisors cannot rely on an answer they have no way to verify.
The PM who barely codes but understands the system
They start by collecting a hundred questions that were genuinely asked, find that half concern three procedures, check who is allowed to see what, and agree with the team on a behaviour under doubt: cite the source or abstain. They do not choose the architecture. The first version covers a narrow scope, cites its sources, and gets used daily.
The second is not better because she codes less. She is better because her technical understanding was sufficient to set the right constraints, and because her energy went into the problem rather than the demo. The ideal case, obviously, combines both: a PM who prototypes fast and frames well. The scarce skill is the second one.
PM and PO: two different technical questions
Confusing the two roles muddies most debates about technical depth. The Product Owner works at feature level: specifying expected behaviour, defining evaluable criteria, deciding what is acceptable and what is not, tracking quality over time. Their technical depth serves the precision of the specification.
The Product Manager works upstream and wider: which problem deserves attention, for which user, with what value, in what sequence, at what opportunity cost. Their technical depth serves judgement: telling a feasible path from an attractive but expensive one, sensing what a model will plausibly make possible within the product's scope, and avoiding commitments the system cannot honour.
An organisation where the PM only asks the value question and the PO only the specification question works fine. An organisation where neither understands the system's behaviour ships features nobody knows how to evaluate.
Getting better without chasing the wrong goal
The most effective path is not a programming course but a usable understanding, built in this order.
- 1
Watch the system on real cases
Gather cases from the field — not invented examples — and look at where behaviour degrades. It is the fastest source of concrete technical understanding available.
- 2
Name what you observe correctly
Tell poor retrieval from poor phrasing, a context limit from missing data, a formatting error from a substantive one. That vocabulary precision immediately improves conversations with the team.
- 3
Learn to evaluate before learning to build
Being able to assemble a business test set, define what "good answer" means and compare two versions is worth more, for a PM, than being able to call an API.
- 4
Prototype, if the context justifies it
Add prototyping ability where the organisation actually benefits: small team, intensive discovery, technical product. Otherwise that energy pays off better elsewhere.
This progression has one advantage: every step is immediately useful, including for a PM who will never write code. And it avoids the mirror trap — a PM who learned to code but still cannot say, looking at a system's answer, whether the business can accept it.
Key points
- The real question is not "can you code" but "how deeply do you understand the system you are steering".
- Level 1 — probabilistic behaviour, data, evaluation, cost, latency, prototype limits — is not optional.
- Level 2 — testing a hypothesis, reading documentation, prototyping, talking precisely — changes discovery speed.
- Writing code is a real accelerator in some contexts, not an entry requirement for the role.
- A PM who codes but frames badly ships technically clean features nobody uses.
- The PM owns value and strategy; the PO owns specification and feature-level trade-offs.
- AI Product
- AI literacy
- Use-case framing