Preface

For most of the past twenty years, the binding constraint on enterprise product management was execution. The question a PM answered every week was some version of “can we build it?” Scope, cost, dependencies, engineering capacity. The craft was translating messy human needs into something a team could ship inside a quarter.

That constraint is gone.

AI collapsed the build side of the equation faster than most of us noticed. Prototypes that used to take six weeks take a weekend. Integrations that used to require a dedicated squad run on a foundation model and a handful of tools. For a growing share of what enterprise teams do, “can we build it?” has stopped being the interesting question at all. The interesting question is now “should we, and if so, what should it actually do, and what happens when it is wrong?”

That shift is the reason this book exists.

In healthcare, the field that has been running the longest and most rigorous AI experiment, most AI pilots never reach production at scale. The models usually work. The projects fail on something else: judgment about which problem to attack, how to specify what right looks like, what happens when the system is wrong, and who is accountable when it is. That is PM work. It is not secondary to engineering capacity. It is the binding constraint that replaced it.

This book is for product managers who are good at their jobs and honest about what they do not know.

You have shipped enterprise software. You have run workshops, argued over priorities, and delivered systems that real people use to do real work. You understand vertical markets, customer pain, and the discipline of translating messy human needs into something an engineering team can build. Now someone has put the word “agent” on your roadmap, and you are being asked to design a system that acts on its own. Not a workflow automation. Not a chatbot with a better prompt. A system that makes decisions, takes actions, and compounds those actions over time, sometimes faster and at larger scale than the humans around it.

Three ideas run through this book. One: AI is probabilistic, not deterministic, and that changes the PM toolkit at the level of first principles. Two: you are designing two products at once, the agent and the human system that supervises it. Three: the supervisor is not a fixed input. The supervisor population is being reshaped by the same deployment that depends on it. If you hold those three ideas in view through every chapter, the rest of the book is a toolkit. If you forget them, the frameworks will produce the right answers to the wrong problems.

Three running case-study threads, used selectively to fit the argument. Software engineering, because that is the closest empirical evidence to every PM’s daily work. Healthcare and clinical AI, because the evidence base is sharpest, the regulation is most rigorous, and the stakes anchor what irreversibility actually means. Enterprise SAP and operational systems, because that is the vocabulary most PMs reading this book live inside. Each chapter picks the thread that fits the argument best. No chapter is single-thread. No thread is decorative.

One distinction before the roadmap, because the phrase “AI product management” is doing two jobs and they are not the same job.

The first is using AI to improve product management: the tools, the prompts, the agents that draft the analysis and stress-test the argument before anyone else sees it. That is a skill set. It compounds quickly, and before long every PM will have it. It multiplies output. It does not supply judgment.

The second is using product management to improve AI: designing the agent and the supervisory layer around it, setting the autonomy and the behavior it may never cross, and carrying responsibility for what the system does to people who will never touch it. That is a mindset rather than a skill set, and not every PM will make the shift.

This book is about the second. The first appears late, in the field manual, for two reasons. A PM who works that way builds the judgment the second job runs on. And it would be strange to write a book about agents without saying how I use them.

Chapter 1 is short, and it is the argument the rest of the book is built on. Read it first, whatever else you skip. If you are strong on product but light on AI, Chapter 2 starts with the technical foundations you need, explained without jargon and grounded in concrete examples. If you already have AI fluency, skip to Chapter 3 and start with the role shift that reframes the rest.

Chapters 4 through 6 are the design half of the job: deciding when an agent is the right answer, writing the two briefs that turn that decision into a buildable spec, and the four runtime artifacts every agent needs before it ships. Chapter 6 also expands substantially on adversarial security, because the threat model for agentic systems has matured fast and the runtime artifacts have to ship with it. Chapters 7 through 10 are the operating half: evals, production observation including the observability literacy a PM now needs, change management for the humans the agent now works with, and the maintenance problem nobody budgets for, the slow degradation of a deployed agent and of the instruments built to watch it. Chapters 11 and 12 widen the lens to frameworks, governance, and the people the agent affects who never touch the product. Chapter 13 names the institutional gap underneath all of it: the personnel infrastructure that does not yet exist for AI agents. Chapter 14 names the judgment the rest of the book keeps asking you to supply, and the fact that nothing certifies it. Chapter 15 compresses the whole book into a field manual of checklists.

If you are an experienced PM who already knows the frameworks, this book will not re-teach them. It will show you where they bend under agentic conditions, what new artifacts you need, and how to design the supervisory system that most teams are not building.

The voice throughout is that of someone who has been on both sides: a physician who has managed patients under general anesthesia while machines monitored their vital signs, and a product leader who has shipped enterprise software across SAP, Walmart, Microsoft, and regulated health technology. The clinical-product intersection is where most of the examples in this book come from, and why.

One more thing. This book will not hype what agents can do. It will help you specify what they should do, what happens when they are wrong, and who is accountable. Those are the questions the market is not asking clearly enough. They are the questions that will separate products that last from demos that do not survive their first production incident.

Every technology era gave ancient business processes a better vessel. R/2 automated integration. R/3 standardized global processes. ESA opened the API surface. HANA eliminated batch. None changed what the system understood about the work. Agentic AI is the first vessel that begins to reason over the logic it carries. That is the shift you are being asked to design for, whether anyone on your team names it that way or not.

---

How to Read This Book

Five ideas recur through the whole book. Hold them in your pocket as you read; every chapter is, in some way, about one or more of them.

If you read this book in order, the chapters compound. Chapter 1 states the problem the rest of the book answers. Chapter 2 establishes the vocabulary. Chapter 3 reframes the PM role around it. Chapter 4 decides whether to build. Chapter 5 turns that decision into the two briefs. Chapter 6 designs the runtime. Chapter 7 evaluates before launch. Chapter 8 observes after. Chapter 9 manages the human transition. Chapter 10 names the slow failure mode that makes month eighteen the hardest test. Chapter 11 turns frameworks into boundaries. Chapter 12 adds obligations to the affected person. Chapter 13 names the personnel infrastructure that has to be built for any of this to work at the institutional level. Chapter 14 names the judgment none of it runs without. Chapter 15 is the field manual you go back to.

Underneath the chapters is a simpler shape, six phases the work moves through, and it is worth holding in mind as you read.

• Phase 0, AI Literacy: the team becomes fluent enough to specify an agent and catch it when it is wrong (Chapter 2).
• Phase 1, Discover and Decide: you decide whether to build at all, and produce the go or no-go (Chapter 4).
• Phase 2, Design: you write the two briefs and the four runtime artifacts (Chapters 5 and 6).
• Phase 3, Eval: you prove readiness with evals run many times, not once (Chapter 7).
• Phase 4, Observe: you measure what the agent is actually doing in production (Chapter 8).
• Phase 5, Operate: you keep it honest as it drifts, and govern, supervise, and eventually retire it (Chapters 9 through 13).

The field manual in Chapter 15 lays these out as a one-page table of phase, deliverable, and the question each phase exists to answer. If you ever lose the thread, find the phase whose question you cannot yet answer.

If you read this book by chapter pull, it works too. Each chapter is self-contained with cross-references where they matter. Each chapter opens with its own short pocket list, the two or three of the five ideas that chapter leans on hardest, and carries a concept box for its keystone idea. Those are the load-bearing definitions. The checklists, worksheets, and red flags are the apparatus you take into your own work.

What this book asks of you is not new vocabulary or new frameworks. It is the willingness to design two products simultaneously, to maintain that design across the deployment’s operational life, and to take responsibility for the people the agent will affect who will never see the interface. That is more than most agentic AI books ask. It is the work the discipline actually requires.

---

A note on the evidence. This book makes claims about what agents do, what they cost, and what goes wrong when they act on their own. A claim is only as good as what stands behind it, so here is what stands behind each one.

The evidence comes in tiers, and the tier is named wherever a case appears. Peer-reviewed studies and primary regulatory text carry the most weight. Where a number depends on one, it is cited, and the number is the published number, not a rounded or friendlier version of it. Documented industry incidents are real events drawn from primary reporting or a first-hand account; they are named where naming is possible and carried as an instance of a pattern, not a verdict on one company. Litigation-stage allegations are exactly that: presented as alleged, because discovery is not finished and neither is the case. Vendor and company claims are labeled as such, because a company reporting that its own agent did the work of seven hundred people is making a marketing statement, not publishing a measurement. My own cases are the clinical and product situations I have been close to, offered as a practitioner’s judgment rather than data. And a few scenarios are illustrative composites, built from a documented failure pattern rather than one company’s exact story; where a case is a composite, the page says so.

This book has a narrower job than the companion volume. It is a working PM’s field guide, not the deep evidentiary treatment. Where a claim needs its full sourcing, the citation lives here in short form and the fuller academic and primary-source trail is in the companion volume, Why Agentic AI Products Fail, which this book cross-references rather than duplicates.

I flag this because the failure mode in a field this loud is to launder a vendor’s press release into a fact, or a plausible story into a statistic. I have tried not to. Where a figure is the kind that decays in months, I say so at the point it appears rather than asking you to guess whether it is still current. The facts are dated to mid-2026.

A note on the examples. You will find clinical and healthcare examples throughout this book, used on purpose rather than as decoration. This is not a healthcare AI book. Medicine has been running the highest-stakes AI experiment in the world for decades, under the strictest regulation and the least tolerance for a confident wrong answer, and it has published the results, failures included. The single-agent supervision problem this book is about, one agent, one supervisor, one boundary, was worked out earliest and most rigorously in a hospital, not a software company. When I reach for a clinical example, it is because that is where the evidence is most mature and the lesson transfers most cleanly to the agent on your roadmap.

---