Enough of the economics, the engineering and the failure modes to make good calls about what to build with a model.
The hard part of a machine learning feature is rarely the model. It is deciding which decision is worth automating, what accuracy would be good enough, and what happens to a user when the output is wrong. This list is for product people who have to hold that conversation with a data science team, opening with the economic framing, working through the technical grounding and the systems that keep a model alive in production, and closing with the data foundations and the harms worth checking for.
Agrawal, Gans and Goldfarb treat machine learning as a fall in the cost of prediction, then ask what becomes valuable once prediction is cheap. Breaking a task into prediction, judgement, action and outcome is the most useful planning tool in this list.
Burkov covers supervised learning, model evaluation, feature engineering and the main algorithm families at the level you need to follow a technical conversation. Short enough to read in a weekend and specific enough to be worth the weekend.
Huyen on building applications on top of foundation models, covering evaluation methodology, retrieval, finetuning and the cost of inference. The evaluation chapters matter most, because that is where these products usually come apart.
The lifecycle around the model, including training data, deployment, monitoring and the distribution shifts that quietly degrade a live system. Read it to understand what you are committing the team to after launch rather than before it.
Provost and Fawcett teach the reasoning rather than the tooling, so you can judge whether a problem is really a classification problem and what a fair evaluation would look like. Written for the person commissioning the work.
Reis and Housley on the pipeline underneath every model, from ingestion and storage through to serving. The data engineering lifecycle explains why the answer to your feature request is so often a data availability problem.
O'Neil on the three properties that turn a model into a harm, being scale, opacity and damage. A short checklist to run over anything you are about to put in front of real users.
Every model needs training data, and this is the clearest account of what gets collected, what can be inferred from combining sources, and what that costs the people involved. Read it before you decide what your product should gather in the first place.