Seven books that close the gap between understanding your product and understanding what it is made of.
You do not need to write code to be credible with engineers, but you do need to follow the constraint they are describing when they push back on a request. This list is ordered by how quickly each book pays for itself. The first two can be read in a weekend and change how you write requirements, the middle ones give you the vocabulary for architecture and release conversations, and the last two are references to reach for when a data or machine learning question lands on your desk.
The plain language tour of how software works, covering the internet, databases, operating systems, security and the business models built on them. Written for exactly this audience and short enough to finish before your next technical review.
Lauret treats an API as a product with users, which is the framing that lets a product manager hold an opinion about one. You come away able to review an endpoint design and say something more useful than yes.
Once you write your own queries you stop waiting a week for an answer you could have found yourself. DeBarros starts at installing the database and builds up through joins, aggregation and functions at a pace that assumes no background.
Richards and Ford explain the architecture styles and the characteristics they trade against each other, which is what your engineers mean when they call something a tradeoff. The material on architecture decision records is immediately usable in your own writing.
Understanding the pipeline is what lets you tell a release that is genuinely risky from one that is merely unfamiliar. It also shows you what to fund when every deployment needs a weekend and three people on standby.
Kleppmann on replication, partitioning, transactions and consistency, which is the material behind most of the estimates you are handed for anything at scale. Dense, and the chapter summaries carry a great deal if you read nothing else.
Enough of the vocabulary and the reasoning to follow a modelling conversation, in a form you can finish across two sittings. Read it before you commit to a roadmap item that depends on a model behaving well.