Ship AI that runs in the customer's own cloud, data centre or offline site, and keeps its promise there.
Outcome contracts, the least machinery that works, data contracts, capacity, latency budgets, evaluation with intervals, releases, offline mode and handoff, with a ten-worksheet toolkit for the deployment PRD.
Guide PDFs and toolkits download with paid Premium while it is active, or with complimentary access we have approved. Days earned through referrals open the rest of the site, not these files.
Promise / size / ship / hand over
Pages
67
Chapters
25
Diagrams
23
Dated sources
31
Worksheets
10
What does systems engineering mean for an AI product manager?
Many enterprise customers will only buy AI that runs in their own environment: a utility's cloud tenant, a bank's data centre, a plant floor with no internet. Then the product is the whole package: what it promises, what it needs from the customer, how it behaves when parts fail and how the customer's engineers keep it healthy.
This guide follows one fictional vendor through four customer deployments, from rewriting a request as a measurable promise to sizing GPUs, dividing a latency budget, judging answers with honest intervals, shipping releases a customer can inspect, running offline and handing over. You learn the decisions a PM owns and how to defend them to customer architects and in interviews.
THREE COMPLETE PAGES, FREE TO READ
Judge the reasoning before you decide.
Each preview is a real page from the PDF. Open one to read it at full size.
Page 27
Size the hardware from memory and peak load
A worked GPU estimate a customer can check: weights, cache per request, the morning burst and the idle months.
Page 40
Build an offline mode with its own promises
What an AI system promises on a plant floor with no internet, and how one package and visible freshness keep it.
Page 50
Manage the queue, then make a release reversible
How a more accurate model swamped a review team, and the tripwire that rolled it back on day two.
25 CHAPTERS / 6 PARTS
From the product decision to a design you can defend.
The promise
Rewrite the request as a measurable promise, pick the least machinery that keeps it, agree data dependencies and keep evidence intact to the answer.
01Rewrite the request as a measurable promisep. 7
02Pick the least machinery that worksp. 9
03Agree the data dependencies in writingp. 11
04Keep evidence intact from document to answerp. 13
Inside the system
Search only what the asker may see, give the model an auditable context, treat models as replaceable services, write safely and keep permissions out of the model.
05Search only what the asker may seep. 16
06Give the model a context you can auditp. 18
07Treat the model as a replaceable servicep. 20
08Write to customer systems safelyp. 22
09Decide permissions in code the model cannot reachp. 24
Size it
Size hardware from memory and peak load, split the deadline across every step, reuse results only where valid and measure with intervals.
10Size the hardware from memory and peak loadp. 27
11Split twenty seconds across every stepp. 29
12Reuse results only where they are validp. 31
13Measure the promise and its uncertaintyp. 33
Ship into their estate
Decide which environments you support, ship inspectable releases, build an offline mode, monitor the promise and hand over what the customer has practised.
14Decide which environments you supportp. 36
15Ship releases as one inspectable packagep. 38
16Build an offline mode with its own promisesp. 40
17Monitor what the customer was promisedp. 42
18Canary the release, then hand it overp. 44
Four engagements
Follow a cloud tenant, a review queue, an offline plant floor and an overnight batch through their first serious failure.
19Case A: inspection answers at Ostrava Energyp. 47
20Case B: supplier documents at Lindqvist Componentsp. 49
21Case C: shift handovers on an offline plant floorp. 51
22Case D: nightly shipment enrichment at Midland Freightp. 53
Prove and defend
Write the deployment PRD, defend the design in a clinic and plan your first six weeks.
23Write the deployment PRDp. 56
24Design clinic: defend a customer-run AI systemp. 58
25Your first six weeks on a customer deploymentp. 60
WORKED INCIDENTS
Four engagements, worked from the evidence.
Each fictional deployment runs somewhere different and fails differently. Each asks what a PM must answer: what was promised, what broke, which rule caught it and what changed.
Customer cloud / mapping out of step
The canary that caught a version mismatch
Version reference tables with the release, check versions at startup and keep a canary slice for every past failure.
Hosted / review rate up 15 points
The better model that swamped the reviewers
Plan review capacity like a service and give every release a tripwire on the work it creates downstream.
Offline site / eight-minute clock drift
The night the order was wrong
Order events by each source's sequence, sync plant clocks and show drift before it misleads.
INCLUDED / 14 FILES
Ten worksheets for the deployment PRD.
The guide ships with ten editable worksheets and three spreadsheets that become the sections of a deployment PRD and the documents a customer's compliance, platform and security teams will ask for.
Start with the outcome contract and the capacity model. Together they answer the two questions every customer asks first: what exactly are you promising, and what will it take to run?
These questions, concepts and lessons pick up where the chapters leave off. Each link also sits, clickable, in the chapter it supports, and keeps its own access level on the site.
The decisions that make an AI system predictable in someone else's environment: the promise and how it is measured, the least machinery that keeps it, the capacity and latency it needs, how it fails, and how a release reaches a customer who controls the servers.
Do I need an engineering background?
No. It is written for product managers. It includes a few short calculations with round numbers, such as a GPU estimate and a confidence interval, so you can follow and challenge an engineer's numbers, but it never asks you to write code.
Is this only for on-premises products?
No. It covers four deployment profiles: vendor-hosted, the customer's own cloud tenant, the customer's data centre and offline sites. Most of the guide applies to any AI product with enterprise customers.
Which sources does it use?
Google's SRE books, AWS guidance, PostgreSQL, pgvector, Kubernetes, OpenTelemetry, OWASP, Temporal, vLLM and research papers on retrieval, LoRA, QLoRA and model serving, with 31 sources checked on 27 October 2026. Research is cited for the mechanism it shows, under the authors' conditions.
How current is it?
Product facts are dated October 2026. The methods it teaches, sizing from peak and memory, budgeting deadlines and judging with intervals, outlast any particular model or GPU.
What is in the toolkit?
14 files: ten editable worksheets from the outcome contract to the handoff plan, plus CSV versions of the data contract, the capacity model and the evaluation plan. Each has one worked example from the guide.
Will this help in AI PM interviews?
Yes. Chapter 24 is a design clinic of ten system design prompts with a rubric and worked answers, and every chapter links to related practice questions. Capacity, latency and self-hosting trade-offs come up in platform and enterprise AI PM loops.
Is it included in Premium?
Yes. The full PDF and toolkit come with paid Premium while it is active, or with complimentary access we have approved, and there is nothing extra to buy. Anyone can read three full sample pages first. Days earned through referrals open the rest of the site, not the guide files.
How was it produced?
AI tools helped with research, source checks, drafting and the cover art. The diagrams are vector figures written in code. Basalt Labs, its four customers and every person in its scenarios are invented. This edition is ready for publisher review, and automated or AI review is no substitute for an independent human editor signing it off.
