Enough systems knowledge to hold your end of an engineering conversation, plus the delivery and platform material the role runs on.
A technical product manager is judged on whether engineers find the conversation worth having, and that depends on understanding constraints rather than on writing code. This list starts with the plain language grounding, moves into the systems and delivery material that explains the tradeoffs engineers keep raising, and ends with the platform and machine learning topics that increasingly land in the role. Read the first two in order and take the rest as the problems arrive.
The plain language grounding in how the internet, databases, operating systems and security actually work. Start here if your background is not engineering, because everything further down the list assumes it.
Kleppmann covers replication, partitioning, transactions and consistency in enough depth that you understand what your engineers mean by a tradeoff. Dense, and the chapter summaries carry a lot on their own if you read nothing else.
The twenty four capabilities that predict delivery performance, with the research method published in full. This is the evidence to cite when you are trying to fund tooling and platform work.
The deployment pipeline in detail, including testing strategy, configuration management and database change. Read it when release frequency is the thing limiting how quickly you can learn anything.
Cognitive load as a design constraint, and the case for a platform team offering its work as a service. Essential reading if your product is an internal platform or an API rather than a screen.
Why operations keeps blocking you, told as a novel with the Theory of Constraints underneath. The quickest way to understand the incentives on the other side of a handover.
Huyen on building applications on top of foundation models, covering evaluation methodology, retrieval, finetuning and inference cost. Specific about the failure modes and how you would measure each one.
An economic frame for machine learning, treating it as a fall in the cost of prediction and asking what that makes valuable instead. Useful for deciding which tasks are worth automating at all.
The technical half of the role only pays off when the product half is sound. Cagan covers the prototype types and the feasibility risk that a technical product manager is best placed to reduce early.