“Should a Technical Product Manager write code?” comes up often. I enjoy poking at code, checking a claim with SQL, and getting lost in logs before finding the one useful line. I still think the question starts in the wrong place. A technical PM does not have to write production code. They do need to understand what their product decision touches inside the system.
Being technical is not about acting like an engineer or using the most jargon in a meeting. It is being able to follow an API call, understand where data changes, find the right signal when something breaks, and ask, “If we ship this quickly, where will it hurt later?” Coding helps me learn those things. It is not the only measure.
Technical fluency is a map, not a ladder
Not every product manager needs the same depth. A content product and a regulated energy or payment platform create different technical responsibilities. I group technical fluency into five areas:
- Product and domain: Which real-world process does the system represent?
- Data: Which events and metrics define success, and can I verify them with SQL?
- APIs and integrations: Do I understand requests, responses, errors, retries, and idempotency?
- Architecture: Which services, tenants, and dependencies does a change affect?
- Operations: Do I know what to inspect during release, monitoring, rollback, and incident response?
In an eMSP product, a user may only tap “start charging.” One action on the screen. Behind it sit authorization, roaming, charger state, tariffs, transactions, and billing. A PM does not need every protocol message memorized; I certainly do not. We should still be able to go one step beyond “the backend should take a look.”
What is the minimum useful level?
I believe a technical Product Manager should be able to do four things:
- Ask the right question. Is the operation synchronous or asynchronous? What happens on retry? Where is the tenant boundary?
- Understand the trade-off. Which debt or operational risk are we accepting for faster delivery?
- Read the evidence. Does the log, SQL result, API response, or dashboard support the claim?
- Verify delivery. Can we distinguish “it was deployed” from “the user problem was solved”?
Those four abilities do not make me an engineer. They help me understand why I should pause when an engineer says a retry may create the same transaction twice. That is where the value is for me.
Too technical can be a problem too
A Product Manager with insufficient technical fluency can delegate both the solution and the problem. Tasks become vague, edge cases appear late, and the definition of success becomes “the ticket is closed.”
At the other extreme, a Product Manager can become attached to a specific endpoint, table, or framework and prescribe the implementation. The team’s solution space shrinks, and the PM starts managing their own technical idea rather than the customer problem.
The balance is to own the problem and outcome while designing the solution with the specialists.
How I assess my own depth
Instead of asking whether I “know” a technical topic, I use three questions:
- Can I make a meaningful decision in this area?
- If I cannot decide, can I ask the right expert the right question?
- Can I independently check whether the result is correct?
If the answer to all three is no, I have a learning gap. If the answer is yes, I can carry technical product responsibility even if I am not the person writing production code.
There is still a lot I do not know, and that is part of what keeps the work interesting. A log line, a small SQL query, or one question from an engineer can teach me something new. The goal is not to be the best developer in the room. It is to translate between the user, the business, and the system without losing the meaning. Technical depth follows when curiosity stays alive.