Prologue: The City and the Checkpoint

The city is clean. Too clean.

Advertisements ripple across glass towers as you pass, adjusting themselves to your gaze, your purchase history, your pulse, perhaps even the quiet little hesitation your bank account makes when you linger too long in front of something expensive. Electric traffic slides silently beneath lantern-red signals. Delivery drones move overhead with the calm confidence of mechanical swallows. Somewhere far above the street, a thousand models negotiate prices, identities, recommendations, permissions, and reputations without troubling the humans below with the details.

And every word you write passes through a checkpoint.

The email to your daughter’s school. The article you spent three nights editing. The angry note to an insurance company. The resignation letter. The sonnet. The complaint. The confession. The late-night screed about the creeping death of civil society you wisely decide not to post until morning.

A black-box oracle leased by the platform examines the prose against a hidden key. It does not care whether the argument is true, beautiful, stupid, malicious, sincere, or written after three bourbons while listening to Mahler.

It counts tokens, frequencies, statistical residues, green flags on an invisible scorecard only the oracle can see.

You do not know the checkpoint exists until the letter arrives.

“Your content has been flagged as likely AI-generated. To appeal, please verify your identity through our Provenance Verification Portal. Additional verification charges may apply.”

The fee is modest.

Per query.

Naturally.

It hardly feels like a surrender. More like a convenience charge for a little additional safety, one thin slice of liberty exchanged for the comfort of knowing that somebody, somewhere, has checked the paperwork.

The city hums on. Somewhere in Brussels, a well-meaning committee chair stands beneath flattering lights holding a document labeled Article 50, smiling with the serene satisfaction of someone who believes a difficult problem has finally been placed inside a sufficiently official binder.

Somewhere in California, a frontier-model executive watches the same ceremony and sees something else entirely.

Recurring revenue.

And somewhere beyond the city walls, beneath an old cedar roof where the neon no longer reaches, a ronin draws a whetstone slowly along the edge of a blade, not because he seeks a war, but because he has learned that when emperors begin stamping golden seals on the truth, it is wise to inspect the seal.

Act I: The Golden Seal

It began, as most dangerous things do, with a perfectly reasonable desire.

Synthetic media was spreading. Deepfakes were improving. Political manipulation, fraud, plagiarism, impersonation, automated propaganda, and industrial quantities of Confident Nonsense had become cheap enough that almost anyone with a browser could play.

Governments wanted accountability. Universities wanted certainty. Publishers wanted provenance. Employers wanted to know whether applicants had written their own work. Platforms wanted a way to label machine-generated material before somebody’s grandmother shared it with seventeen cousins and a school board.

The question sounded simple enough:

Can we make AI-generated text detectable?

And one of the frontier companies stepped forward carrying a Golden Seal.

Their language model, they explained, could embed a statistical watermark directly into generated text. Nothing crude like a visible stamp across an image. The mark would live down among the probabilities themselves, invisible to a human reader but detectable by a proprietary system possessing the proper secret key.

Elegant little beast.

A modern language model produces text one token at a time. At each step it calculates a probability distribution across its vocabulary. Before sampling the next token, the watermarking mechanism uses a pseudo-random function, seeded by a secret key and information from the preceding token sequence, to divide candidate tokens into two groups.

Call them the green list and the red list.

The generator then nudges probability toward the green-list tokens. Not enough to make the prose obviously strange, but enough that across a sufficiently long sample the frequency distribution drifts away from what chance alone would predict. With the key, the detector can reconstruct the green and red partitions for each generation step, count the resulting bias, calculate a score, and decide whether the text bears the statistical fingerprint.

The trick can carry more than a simple yes-or-no mark. Multi-bit watermarking schemes can encode a payload by systematically manipulating token choices across successive generation steps. Given enough text, the resulting green-to-red ratio becomes a statistical smoking gun.

Provided, of course, that you possess the key.

Without it, you are staring at ordinary prose and trying to identify one particular grain of sand on a beach while blindfolded and slightly drunk.

This distinction matters because the marketing language around watermarking has a tendency to wander into phrases like “cryptographic robustness,” which makes the whole affair sound considerably more like a digital signature than it really is. A cryptographic signature binds information to a verifiable key through mathematics designed to make alteration evident. A text watermark, by contrast, is a deliberately introduced statistical bias in the model’s sampling behavior.

One is a seal impressed into wax.

The other is a whisper hidden in a crowd.

That does not make watermarking useless. Under the right conditions, it can work very well: long enough samples, known generation conditions, limited editing, access to the correct detector, and nobody deliberately trying to remove the signal.

And there, quietly tucked into the technical footnotes, lives the dragon.

Because the company that generated the text also possessed the secret key. It possessed the detector. It controlled the thresholds. It controlled the implementation details. And when governments, universities, courts, publishers, social networks, and employers eventually needed to verify whether text carried the company’s invisible mark, the company could conveniently provide that service.

A modest fee.

Per query.

Naturally.

Thus the loop closed.

The company generated the text, inserted the hidden pattern, owned the mechanism for detecting the hidden pattern, and could now become the authority institutions consulted whenever they needed to decide whether someone’s words were authentically human.

The Monopoly of Truth had acquired an API.

And an invoice.

A Very Happy Castle

That matters, because the Golden Seal is not merely a technical control. It is an economic machine. Every institution that depends on the detector becomes a customer. Every accusation becomes a verification event. Every verification event becomes a transaction. The frontier laboratory that can afford the watermark, the secret-key infrastructure, the audit regime, the lawyers, and the lobbying also gets to stand safely inside the walls of what will eventually become a very Happy Castle.

The rest of us begin outside the moat.

There is something magnificently absurd about this arrangement, like allowing the imperial mint to manufacture coins, secretly mark the genuine ones, refuse to disclose the marking process, and then charge merchants every time they want to know whether the coins in their pockets are counterfeit.

Yet institutions love a seal because a seal converts ambiguity into a mark: approved, rejected, human, machine, safe, suspect. The messy business of judgment becomes a number, and numbers, unlike people, arrive at meetings wearing neckties.

The ronin turns the blade beneath the lamp and studies its reflection.

The Golden Seal shines beautifully.

That is precisely what worries him.

Act II: The Single Precog

The technical danger is not merely that the detector might fail.

Every detection system fails. Spam filters fail. Medical tests fail. Fraud models fail. Radar systems fail. Humans fail with remarkable creativity before lunch.

The danger begins when a probabilistic detector is promoted from evidence to oracle.

Think of Minority Report, only remove two of the three precogs. The remaining precog floats quietly in the tank, whispering machine, while the institution outside treats the vision as fact. There is no dissenting signal. No transparent mechanism. No way for the accused to inspect the detector, reproduce the judgment, examine the watermark key, interrogate the threshold, or meaningfully cross-examine the model.

You receive a confidence score.

The score says 83 percent.

Eighty-three percent of what?

Never mind. There is a number.

The student insists she wrote the essay. The journalist insists he wrote the column. The job applicant insists the writing sample is his. The professor, editor, hiring manager, or administrator is now trapped between a human saying I wrote this and a proprietary detector saying probably not.

Institutions tend to side with the machine for a simple reason: the machine has decimal places.

The accused now carries the burden of proving a negative against a mechanism they cannot inspect, which is how a useful forensic signal quietly mutates into Provenance Theater: a probabilistic tool wrapped in an institutional workflow stuffed inside an authority structure that eventually forgets the probability part.

The watermark does not need to be infallible to become dangerous.

People merely need to behave as though it is.

Act III: The Compliance Moat

Then the Golden Seal acquires something more powerful than an algorithm.

A deadline.

Article 50 of the EU AI Act arrives on the calendar, carrying requirements around the detectability and marking of AI-generated content. The precise obligations vary with modality, implementation, and the codes and standards that eventually grow around the law, but the direction of travel is unmistakable: synthetic content should become identifiable.

For a frontier laboratory, compliance is annoying in the same way first-class airport security is annoying. There will be lawyers, technical committees, reporting systems, audits, meetings, documentation, model updates, compliance officers, and perhaps an entire Responsible Provenance organization with its own VP, Slack channels, quarterly OKRs, and an annual offsite somewhere with excellent pastries.

They can afford it.

Tuesday, basically.

The interesting problem lives outside those towers, among the open-weight models whose parameters can be downloaded, copied, quantized, fine-tuned, merged, modified, redistributed, and run on hardware belonging to people the original developer has never met.

An open-weight model is not a cloud service over which the original provider retains permanent operational control. It is, at its most literal, a collection of floating-point parameters and code sitting on somebody else’s machine.

And here the requirement for a persistent, tamper-resistant watermark runs directly into the reason open weights are useful in the first place.

The owner can change them.

Suppose you embed watermarking behavior into the generation stack. The user can remove the stack. Suppose you bias the model so its outputs exhibit a particular token distribution. Fine-tuning shifts that distribution. Suppose some watermark-related behavior is entangled in the weights. A few epochs of additional training on clean text adjust millions or billions of parameters and can weaken the original statistical signature. Suppose you hide a secret key somewhere in the software.

The user owns the software.

There is an almost Zen-like contradiction here: the more genuinely modifiable the model is, the less credible permanent hidden enforcement becomes.

You can permit arbitrary modification.

You can guarantee persistent secret behavior.

Pick one.

Mathematics is stubborn that way.

Regulation, naturally, has no such limitation and may happily request both.

For a university lab, small developer, independent researcher, or three-person startup, the problem therefore becomes larger than writing a watermarking function. They may need monitoring, documentation, legal review, downstream controls, evaluation infrastructure, audit trails, and some defensible argument about what happens after somebody downloads the model and turns it into something its original authors have never seen.

The frontier company sees a compliance requirement.

The independent developer sees a moat.

Nobody has to explicitly outlaw the open model. That would be crude, politically messy, and liable to attract people carrying signs. Far easier to make lawful participation sufficiently expensive that only organizations with a legal department, policy team, and seven-figure compliance budget can comfortably play.

The moat fills itself.

On one side stand the laboratories, governments, universities, and giant enterprises that can afford the bridge. Inside the Happy Castle, compliance is another line item. Another procurement contract. Another team. Another audit. Another cost that can be passed downstream to customers and taxpayers.

Outside are the serfs: academics, hobbyists, small companies, independent writers, students, open-source maintainers, and anyone else who lacks the money or political power to turn regulation into an operating expense.

They are cheerfully informed that everyone still has equal access to the kingdom.

They merely need to swim.

And pay.

The beautiful thing about a moat is that the people inside can call it protection while the people outside experience it as distance. Each new control makes the bridge narrower. Each new compliance requirement raises the toll. Each new toll pushes another little slice of money and power toward the people already standing safely behind the walls.

The ronin watches from the reeds and understands the maneuver.

You do not always destroy a commons by closing the gate. Sometimes you simply start charging admission to oxygen.

Act IV: The Safety Illusion

Unfortunately for the Golden Seal, the literature contains an impolite amount of bad news.

Text watermarking can be remarkably brittle under transformation.

A watermark based on token-level statistical bias depends on preserving enough of the token choices that produced the signal. Change those choices, and the detector begins losing the trail.

A paraphrasing model does exactly that. It attempts to preserve semantic meaning while selecting a different sequence of tokens from its own probability distribution. If the original generator systematically favored green-list tokens and the second model knows nothing about that secret partition, the paraphrased version begins wandering back toward chance.

Published attacks have shown dramatic reductions in detection performance after paraphrasing, in some cases pushing previously high detection rates down toward the floor. Round-trip translation creates another problem because translation changes word choice, syntax, and tokenizer boundaries. English becomes German, German becomes English, and the pseudo-random sequence alignment needed to reconstruct the original green and red partitions can be shredded along the way.

The meaning survives.

The fingerprint goes missing.

There are more elegant attacks. Researchers can use gradient-based optimization to discover adversarial token sequences that manipulate generation behavior in ways that reduce watermark detectability. A short string of apparently nonsensical tokens, something with the aesthetic dignity of jazz clarinet oboe summary, can under the right conditions steer output toward low-entropy or detector-hostile behavior.

The phrase itself is not magic. The optimization process is doing the work, searching token space for combinations that reduce the detector’s confidence.

Still, there is something wonderfully Douglas Adams about spending millions of dollars constructing an international provenance regime only to discover that part of it may be embarrassed by a phrase resembling the inventory list from a middle-school band closet.

California’s approach offers an instructive contrast. Its AI transparency legislation has treated raw text differently from modalities where watermarking and provenance techniques are more mature, reflecting the uncomfortable reality that reliable text watermarking remains a harder problem.

That distinction matters because the policy conversation often lumps together image watermarking, metadata provenance, cryptographic signing, generated audio, generated video, and text watermarking as though they were different flavors of the same engineering problem.

They are not.

Text is unusually easy to transform without destroying its meaning. Change the pixels of an image too much and you no longer have the same image. Change the words of a paragraph and you can preserve the same argument, emotion, accusation, lie, sales pitch, or threat while replacing most of the surface representation the detector depended upon.

The Golden Seal works best when its subject cooperates.

The propagandist will not cooperate. The fraudster will not cooperate. The state-sponsored influence operation with a rack of GPUs and three shifts of engineers certainly will not cooperate.

The high school student who has never heard of watermark laundering probably will.

So the response is perfectly reasonable. We need stronger verification.

Then stronger identity.

Then stronger enforcement.

A little more safety.

A little less liberty.

Nothing dramatic. Nobody is boiling anybody. The water is simply a degree warmer than it was yesterday.

Marvelous.

We have constructed a burglar alarm optimized for homeowners.

The ronin reads the papers by lamplight and allows himself the smallest smile.

The fortress has walls of paper.

Paper, as history repeatedly demonstrates, has some unfortunate interactions with fire.

Act V: The Laundering Underground

The revolution does not begin in a cave.

It begins with two browser tabs.

In the first, generate text using the compliant frontier model. The model produces its answer token by token, applying the watermarking bias, quietly accumulating the statistical signature as the paragraph grows.

In the second, open another model that does not share the secret key or green-list partitioning scheme, paste the text, and ask it to paraphrase the passage naturally.

The second model generates a semantically similar passage using its own token distribution. It does not deliberately select the first model’s green tokens because it does not know what they are. As enough words are replaced, reordered, expanded, contracted, and resampled, the original bias drifts toward statistical noise.

Run the detector again and the expensive oracle squints.

Nothing suspicious.

It has been defeated by a thesaurus with electricity.

A translation pipeline can accomplish the same thing. English to Spanish. Spanish back to English. Perhaps through French for good measure if someone enjoys unnecessary ceremony. Each transformation changes tokenization and probability structure while preserving enough semantic content for the end-user.

A more permanent wash comes from fine-tuning.

Take an open-weight model and train it for a few epochs on a corpus of clean human text. QLoRA, Quantized Low-Rank Adaptation, makes this accessible on comparatively modest hardware by keeping the base model quantized while learning low-rank adapter matrices rather than updating every full-precision weight directly. The adapter is small. The compute requirement drops dramatically. A consumer GPU that would have been laughable for full model training can become perfectly useful for adaptation.

Train on pre-2023 essays. Tax documents. Public-domain books. Technical manuals. Opera libretti if you are a particular kind of knucklehead.

The model’s generation distribution shifts, and whatever delicate statistical bias the original watermarking behavior depended upon now has to survive a model whose output behavior has been deliberately changed.

This matters because laundering is not some dark art requiring a nation-state laboratory beneath a volcano. The basic ingredients are increasingly ordinary: downloadable weights, cheap fine-tuning methods, local hardware, APIs, translation systems, paraphrasers, and enough automation to turn the whole procedure into a pipeline.

The organized bad actor does not manually paste text between tabs. They create a workflow that generates, paraphrases, translates, resamples, scores, repeats if needed, and publishes. The watermark becomes just another transformation target, something the pipeline learns to push beneath the threshold before the material ever reaches the public.

The people most burdened by the Golden Seal are therefore the people who do not know where the faucet is.

Ignorance becomes the only offense the detector can reliably punish.

There is something operatically cruel about that.

The innocent comply and remain visible.

The guilty automate.

Act VI: The Scapegoat Gambit

At some point the embarrassing questions begin.

Why are watermarked outputs appearing without detectable marks? Why are some human texts receiving suspicious scores? Why can researchers remove the signal? Why are sophisticated influence operations still producing content at industrial scale? Why, after all the announcements, standards committees, compliance programs, procurement contracts, and breathtaking slide decks about trustworthy ecosystems, does the Golden Seal appear mostly capable of inconveniencing students and editors?

The frontier company has two choices.

It can explain that statistical watermarking was always a probabilistic defense with known limitations, one signal among many, useful under constrained conditions but never the universal machine-versus-human oracle that public imagination turned it into.

Or it can find a villain.

Across the moat sits the open ecosystem.

Perfect.

The narrative practically writes itself.

The watermark works, we are told, but open models allow people to launder the text. The watermark works, but unauthorized fine-tuning removes the signal. The watermark works, but uncontrolled local inference creates an ungoverned pathway.

The watermark works, if only everybody would stop doing all the things that demonstrate how the watermark does not work.

Open-weight models become the laundering machines, the dark mirrors, the escape route through which synthetic text slips past responsible provenance systems. The weakness of the control becomes evidence that the things capable of circumventing the control must themselves be controlled.

That is a lovely bit of policy jujitsu.

Build a lock that opens when someone jiggles the handle.

Then regulate handles.

The scapegoat gambit matters because it changes the political question. We are no longer asking whether a particular watermarking technique provides enough value to justify its limitations. We begin asking whether ordinary people should possess models capable of generating unwatermarked language at all.

The ronin hears the shift.

The argument is no longer about the Seal.

It is about who gets to own a sword.

Act VII: The Silicon Edict

Once software cannot reliably preserve the mark against an owner who controls the software, the empire moves downward.

To the hardware.

The idea is technically plausible enough to be dangerous.

Modern secure-computing systems already use hardware roots of trust, secure boot, trusted execution environments, signed firmware, attestation services, and cryptographic chains designed to prove that particular code is running in a particular configuration.

Apply the same architecture to AI inference and the GPU can verify the model, the model can verify its signature, and the inference environment can produce a cryptographic attestation proving that an approved model ran inside an approved runtime with approved provenance controls.

No valid signature, no inference.

No attestation, no distribution.

No provenance certificate, no platform access.

The Silicon Edict is born.

At first the applications will be difficult to argue against because the first applications are always difficult to argue against: election interference, fraud, child exploitation, biological threats, terrorism, synthetic impersonation used to steal Grandma’s retirement account.

Real harms.

Real victims.

Real reasons to want better controls.

Then the machinery exists.

And machinery, once purchased, develops an appetite.

Perhaps only certified models can execute on new consumer accelerators. Perhaps uncertified inference receives a performance penalty. Perhaps cloud providers must reject unregistered weights. Perhaps model hashes must appear on an approved list. Perhaps platforms only accept content carrying attestation from sanctioned generation systems. Perhaps operating systems refuse to load inference runtimes that cannot prove compliance.

One layer at a time, the Golden Seal descends from the text into the silicon, and somewhere along the descent we quietly stop regulating the provenance of synthetic media and begin licensing the machinery capable of producing language.

Call it the Speech License.

Melodramatic?

Good.

Some things deserve brass.

Nobody calls it a mark.

That word carries old baggage.

It is simply verification. Facial recognition. Fingerprint recognition. A cryptographic credential binding you to your device, your approved model, and the things you create.

You can refuse it, of course. Nobody forces you. You simply discover that without it your words become harder to publish, sell, cite, authenticate, monetize, or pass through the gates of the Happy Castle.

And so we present our faces and fingerprints for the privilege of feeding the beast.

For a modest fee.

Naturally.

Nobody surrendered liberty all at once. That would have caused a scene. We surrendered it sensibly: a watermark here, an identity check there, a verification charge because infrastructure is not free, a restriction on troublesome open models because somebody might misuse them, hardware attestation because software controls can be removed, licensing because attestation without enforcement is merely a suggestion.

Each slice purchased a little more safety.

Or appeared to.

By the time anyone notices the water getting warm, the people inside the castle own the well.

The problem is no longer whether governments should regulate harmful uses of AI. Of course they should. We regulate harmful uses of practically every powerful technology humans have managed to invent without immediately setting ourselves on fire.

The deeper question is whether the infrastructure built to control those harms also creates the technical ability to decide which computational systems are permitted to produce language at all.

That capability does not know intent. The GPU cannot distinguish the dissident from the propagandist, the security researcher from the criminal, the teenager experimenting with a local model from the influence operation generating ten million fake accounts.

Hardware attestation is magnificently indifferent to moral philosophy.

The signature matches.

Or it does not.

The oracle has finally acquired a sword.

Technical Interlude: The Arsenal

Before the opera proceeds, it is worth laying the weapons on the table and examining them without candlelight, metaphor, or violins.

Adversarial Suffix Injection

Watermark detectors rely on measurable statistical behavior. If an attacker can influence generation toward token sequences that weaken those statistics, detector confidence can fall. Gradient-based optimization and related search methods can identify adversarial prompt strings whose surface meaning may be nonsense but whose effect on the model is not.

The resulting suffix can be tiny compared with the generated passage. Attackers do not need to understand why every token works. They only need the string.

Research becomes recipe.

Recipe becomes meme.

Meme becomes infrastructure.

The Federated Laundering Swarm

Once laundering can be automated, centralization becomes optional.

Imagine a decentralized network whose nodes contribute inference capacity. A user submits text. One node paraphrases it. Another translates it. Another summarizes and expands it. Another scores it against publicly available detectors. Routing changes for each request.

No single transformation is particularly clever.

The composition is.

The original statistical signature is exposed to multiple independently sampled token distributions. Each pass weakens the relationship between the final surface text and the green/red decisions made during original generation.

It is less a single evasion technique than a washing machine filled with stochastic processes.

The law can shut down a service.

Protocols are more annoying.

The Hardware Backdoor Workaround

If future accelerators enforce model attestation, older hardware suddenly becomes valuable for reasons that have nothing to do with FLOPS.

Pre-attestation GPUs become contraband. Modified firmware appears. Jailbreaks appear. Open accelerators become politically interesting. RISC-V based inference hardware, custom FPGA designs, or other architectures without the mandated trust module become a parallel ecosystem.

Driving computation underground does not make computation disappear.

It makes the topology uglier, more distributed, harder to update, harder to observe, and harder to regulate.

We have seen this movie with encryption, media copying, file sharing, radio, printing presses, and approximately every other attempt to make information obey geography.

The costumes change.

The physics remains stubborn.

Style Cloning

Then comes the technique that breaks the entire philosophical frame.

Fine-tune a model on a person’s public writing.

The generated text begins reproducing their lexical habits, sentence rhythms, recurring metaphors, rhetorical structures, and stylistic fingerprints. A sufficiently rich public corpus makes the problem easier. Journalists, professors, politicians, authors, executives, bloggers, and people who have spent two decades leaving thousands of words scattered across the internet make particularly attractive targets.

Now ask the detector whether the resulting prose is human.

If it says no, it may falsely condemn authentic writing from the person whose style trained the model. If it says yes, it may accept synthetic writing because the model has successfully reproduced the very features associated with the person’s authentic voice.

The defense becomes the attack surface.

The sword turns in the ronin’s hand.

Act VIII: The Samizdat Revival

The Silicon Edict produces the same result broad information controls have produced throughout history: a parallel culture.

At first, the public casualties are obvious. Model repositories receive notices. Hosting providers discover new compliance obligations. The little ollama run command that once turned a laptop into a private inference box becomes the sort of thing a regulator describes as an “unmonitored execution pathway,” which is bureaucratic for we have discovered that your computer can do things without asking us first.

Then the arrests begin.

Not because this is what has happened, but because this is where our fable is headed if the logic is allowed to finish its sentence.

One wet morning, the founders of Hugging Face are escorted from their offices beneath the serene gaze of a compliance drone, charged with maintaining a public bazaar where citizens can obtain models whose weights can be inspected, copied, modified, and run beyond the walls of the approved inference temples. Clément Delangue, Julien Chaumond, and Thomas Wolf disappear into a transport while somebody from the Ministry explains that openness itself was never the crime. The problem was unverifiable downstream modification.

Naturally.

By lunchtime, Jeffrey Morgan and Michael Chiang of Ollama are collected for the still more suspicious act of making those same open models absurdly easy to run on personal hardware. Their old promise had been wonderfully simple: your model, your machine, your data. Under the Silicon Edict, each word becomes evidence.

Your model?

Unlicensed weights.

Your machine?

Unattested compute.

Your data?

Unmonitored information flow.

Three counts.

No waiting.

The repositories do not vanish, of course. Software has always been irritating that way.

Copies already exist on laptops, NAS boxes, external SSDs, university servers, forgotten cloud volumes, gaming rigs, old workstations, and the sort of basement machine whose owner insists the screaming fan is “fine” because technically it has not caught fire yet. Model weights travel as encrypted archives. Quantized versions become especially valuable because a model that once demanded a rack of datacenter GPUs can now be squeezed into hardware that fits under a desk.

Adapters become smaller still. LoRA and QLoRA separate much of the task-specific adaptation from the full base model, which means a specialized capability or style can travel as a comparatively tiny set of learned matrices rather than another complete multi-gigabyte model. A base model may be difficult to move quietly. An adapter can fit on a thumb drive, inside an encrypted attachment, or, with enough poetic license and compression, inside a haiku.

The public commons collapses into private craft.

The official channels remain beautifully safe, auditable, licensed, and increasingly expensive. The Happy Castle glows on the hill while the people who once downloaded a model with a command and a shrug discover that privacy has become a luxury item reserved for people powerful enough to negotiate their own terms.

Everyone else improvises.

And then come the Buddy Clusters.

Nothing dramatic at first. Four friends. Five GPUs. Maybe six if one of them has recently gone through a divorce and made some financially questionable decisions involving an RTX 6090. A private VPN connects machines in three houses. One system holds the model weights. Another contributes VRAM. A third handles retrieval. Somebody’s old workstation becomes the vector store because nobody has had the heart to throw it away since 2021.

Distributed inference is not magic. Large models can be partitioned by layer, tensor, pipeline, expert, or request depending on the architecture and tooling. The network becomes part of the performance budget because activations and synchronization traffic have to cross between machines, which means your glorious neighborhood supercomputer may occasionally run with all the majestic latency of a committee meeting conducted through a drive-through speaker.

But it runs.

That is the point.

A backroom above a repair shop has three mismatched towers humming behind a curtain. A basement in Raleigh has a couple of consumer GPUs connected over 10-gigabit Ethernet because someone finally admitted Wi-Fi was not going to cut it. A professor keeps an old open-weight checkpoint on a workstation that technically belongs to a microscopy lab. A group of friends shares adapters, inference recipes, quantization settings, and the accumulated folklore required to make hardware from four manufacturers cooperate without summoning a demon.

Nobody calls it a datacenter. That would be ridiculous. It is a few friends helping each other with computers in a backroom or basement because the lawful, certified, fully attested version of the same capability now requires money, permission, or both.

The empire calls it a Federated Unlicensed Inference Cell.

The friends call it Thursday.

This is the predictable economics of prohibition. Once capable models exist in downloadable form, regulation can make their public distribution expensive, dangerous, or illegal, but it cannot make every existing copy climb obediently back into the server from which it came. The law changes the distribution channel. Hugging Face becomes encrypted archives. Ollama becomes remembered commands, forks, mirrors, handwritten installation notes, and whatever descendant tool appears next under a name chosen specifically to annoy the Ministry.

The result is not less AI.

It is less visible AI.

The state gains beautiful compliance among the people already inclined to comply while the technically capable retreat into systems designed from birth to avoid centralized observation. The very controls intended to create provenance manufacture an ecosystem in which provenance becomes socially undesirable.

Splendid.

We have invented regulatory dark matter.

The empire can measure the gravitational effects.

It cannot see what occupies the basement.

Act IX: The Library That Ate Itself

Before McBean arrives, we need to visit the library.

Because the Monopoly of Truth does not merely want jurisdiction over the sentences we generate tomorrow. It has developed a rather impressive appetite for the sentences humanity wrote yesterday.

Models must eat.

The open web was the first buffet, a magnificent steaming trough of scholarship, journalism, recipes, message boards, documentation, conspiracy theories, product reviews, fan fiction, medical advice from people named DragonSlayer77, and several billion pages apparently written for the sole purpose of selling replacement garage doors in Omaha.

Eventually the frontier laboratories wanted better food.

Books.

Edited books. Structured books. Technical books. Obscure books. Out-of-print books. Books written before the web began filling with AI-generated material that had itself been trained on material scraped from the web, creating the informational equivalent of repeatedly making soup from yesterday’s soup.

And then reality produced a scene so perfectly suited to this fable that inventing it would have felt heavy-handed.

Anthropic called it Project Panama.

Court filings later revealed an internal description of the project as an effort to “destructively scan all the books in the world.” The company spent tens of millions of dollars acquiring millions of physical books, removed their spines so pages could move quickly through industrial scanners, digitized the contents for training, and disposed of the physical volumes afterward. Reporting on the filings described a project deliberately kept quiet while the company sought the clean, long-form human writing needed to feed Claude.

Buy.

Cut.

Scan.

Train.

Discard.

There is a brutal industrial elegance to it.

Destructive scanning is not technically mysterious. A bound book is slow to digitize because pages must be turned while preserving alignment, focus, and the physical object. Cut away the spine and the book becomes a stack of loose sheets that can be pushed through high-speed document scanners. Optical character recognition turns the page images into machine-readable text. Layout recovery reconstructs headings, footnotes, tables, and other structure. Deduplication removes repeated editions and overlapping material. Filtering strips scanning garbage. The resulting corpus can then enter the same enormous data pipelines used for pretraining.

Efficient.

Scalable.

And fatal to the copy on the table.

To be precise, we should not pretend every volume was the last surviving copy of some illuminated medieval treasure. Anthropic has said the project did not target rare or antique books, and reporting suggests much of the material came through ordinary second-hand channels. Nor should we pretend destructive scanning was invented by AI companies. Libraries and digitization projects have long made hard choices about physical preservation when scanning large collections.

But scale changes the moral texture of a thing.

Millions of books are no longer an unfortunate binding sacrificed during preservation. They are feedstock.

And now booksellers around the world are reporting strange bulk orders for older, obscure, and out-of-print titles, precisely the material valuable to model builders because it predates the flood of synthetic text. Not every mysterious order has been tied to a named frontier laboratory, and we should not manufacture certainty where the evidence does not provide it. But the market signal is real enough to make the scene uncomfortable: old human-written books have become a strategic raw material in the race to build machines that write.

This gives the phrase Monopoly of Truth another meaning.

Imagine an obscure book printed in 1987. Perhaps five hundred copies remain scattered through private shelves, used bookstores, university basements, and boxes nobody has opened since a move during the Clinton administration. An intermediary buys fifty of them. Their spines are cut. The pages are scanned. The physical copies disappear into recycling while their text enters a private training corpus.

The knowledge has not vanished.

Something stranger has happened.

The durable human-readable artifact has been converted into training material for a statistical system whose internal representation cannot be browsed like a library, whose exact training corpus may not be public, whose weights may be proprietary, whose outputs are probabilistic, and whose access can be changed by pricing, policy, acquisition, regulation, or the ordinary corporate ritual of announcing that a beloved product will be sunset at the end of the quarter.

The book once existed as a thing you could lend, annotate, inherit, resell, cite, compare against another edition, leave to your daughter, or discover accidentally on the wrong shelf.

Inside the model, it becomes influence.

Maybe memory.

Maybe a few retrievable passages.

Maybe nothing recognizable at all.

Researchers have already shown that production models can sometimes regurgitate startling amounts of copyrighted books under the right extraction procedures, while other material disappears into the statistical fog. That should make us cautious about saying the model “contains” a book in the ordinary sense.

It does not contain a library.

It contains what digestion leaves behind.

And here the architecture of our fable finally closes its jaws.

The frontier company can acquire part of the historical record, convert it into private training data, destroy the particular physical copies it purchased, build the model that mediates our access to the resulting knowledge, and participate in the emerging systems that decide whether new text is authentic enough to enter tomorrow’s record.

Past goes in through one proprietary gate.

Future comes out through another.

Somebody owns both gates, and the rest of us increasingly rent access to the machinery standing between them.

That is the part the old emperors missed.

The old emperors burned books because they feared what citizens might read.

The new empire has discovered a more interesting arrangement: buy the books, cut the spines, ingest the words, discard the bodies, then sell access to the machine that remembers what the books once said.

For a modest fee.

Naturally.

Read the books first.

Act X: McBean Comes to Town

At this point our Asian science-fiction opera is interrupted by a traveling salesman from a children’s fable, except by now the attentive reader may realize he has been here since the overture.

Sylvester McMonkey McBean finally steps into the light.

He has a machine.

Some citizens bear the mark. Others do not. The marked enjoy status because the mark proves they belong, so McBean offers the unmarked a machine that can add the mark.

For a modest fee.

Naturally.

The newly marked now look exactly like the old marked, which destroys the status value of being marked, so McBean conveniently produces another machine capable of removing the mark.

For another fee.

Stars on. Stars off. Authenticity becomes a transaction and identity becomes a service.

The machine does not resolve the distinction.

It monetizes the distinction.

That is the joke hiding beneath the whole opera. The watermark creates the need for verification. Verification creates fees. Evasion creates stronger controls. Stronger controls create licensing. Licensing creates appeals. Appeals create more fees. Every new failure of the system becomes a reason to purchase more of the system from the people powerful enough to build it.

Replace the star with provenance and the story requires almost no editing.

Human verified. Synthetic identified. AI-assisted certified. Unverified. Premium provenance. Enterprise provenance. Government provenance.

The distinction itself becomes valuable precisely because somebody owns the machine that grants it. Forgery creates demand for verification, verification creates incentives for forgery, new verification creates new laundering, and new laundering creates new verification until McBean drives away with the money and nobody remembers why having a star mattered in the first place.

Douglas Adams would have recognized the resulting bureaucratic ouroboros immediately. It is the shoe event horizon of AI policy, a self-perpetuating spiral in which the primary output of provenance infrastructure becomes demand for more provenance infrastructure.

The Vogons at least filed their destruction orders in triplicate.

We file ours in confidence scores.

Act XI: The Voice Waiting in the Machine

Now I owe you a confession.

Not about regulation.

About what I want to build.

My daughter is grown now, well into that strange season when a child becomes an adult and the relationship shifts without ever quite stopping being father and daughter. She has her own life, her own memories, her own accumulated history of hearing my voice in kitchens, cars, airports, family arguments, bad jokes, unsolicited explanations, and whatever other moments become important only after you can no longer have them again.

Someday I will be gone.

That is not science fiction.

What I would like to leave behind may be.

I have decades of writing, much of it from before 2023, before generative AI contaminated the evidentiary well. Articles. Blog posts. Notes. Technical arguments. Product rants. Stories. Fragments. Old material containing the sentence rhythms, metaphors, obsessions, vocabulary, peculiar tangents, and occasionally successful jokes that accumulated into what my daughter recognizes as me.

And I have recordings.

Talks. Classes. Interviews. Presentations. Ordinary speech. Enough samples of pitch, pacing, pauses, inflection, laughter, hesitation, the little verbal signatures that do not live in prose because writing and speaking are related but decidedly not the same animal.

Put those together and something becomes possible.

Not immortality.

I’m not that full of myself.

A conversational artifact.

A model grounded in my pre-2023 writing, shaped by the corpus I knowingly leave behind, connected to a speech system synthesized from recordings of my actual voice. Something my daughter could sit down with ten or twenty or forty years after I am gone, ask a question aloud, and hear an answer returned in the voice she remembers from childhood.

Not a generic “Dean-like” voice.

Mine.

Not a chatbot improvising from whatever scraps the internet remembers about me.

A bounded system built from material I chose to leave her.

She could ask what I thought about something. Ask for one of the stories she has heard too many times. Ask how I might have approached a problem. Ask why I always insisted that Hope is not a Strategy. Ask about the family. Ask what I meant in an article she found somewhere. Ask some ordinary ridiculous question because ordinary ridiculous questions are most of what family life is made of.

And the machine would answer.

Not because it contains me.

Because it contains enough residue of me to make the conversation feel familiar.

That distinction matters.

I do not want my daughter worshiping an oracle. I want her to know exactly what the system is: a statistical approximation trained on what her father wrote, constrained by what he chose to leave behind, speaking through a synthetic voice reconstructed from recordings of a man who is no longer there.

A ghost with documentation.

A memory that can answer back.

And now the Golden Seal finds itself facing a question that no detector, watermark, attestation chain, or provenance regime was designed to understand.

Is the voice synthetic?

Yes.

Is it authentically mine?

Also yes.

Was the answer written by me?

No.

Would my daughter recognize the thought pattern, the cadence, the joke arriving half a second before it should?

Perhaps.

Is this impersonation?

Technically, yes.

Is it fraud?

No.

Is the system producing machine-generated language?

Obviously.

Is it also part of a daughter’s inheritance from her father?

I would argue that it is.

The detector cannot make that distinction because the distinction does not live in the tokens.

It lives in the relationship.

The compliance portal has no field for that.

There is no checkbox marked:

“My father knowingly trained this from his own pre-2023 writing and voice recordings so I could still talk with him after he died.”

There is no regulatory category for grief.

Bureaucracies are funny that way.

Worse, the burden has reversed again. My daughter does not arrive presumed entitled to the thing I deliberately left her. The model is synthetic. The voice is cloned. The weights are local. The provenance is private. The system raises its eyebrow and she must prove that the ghost belongs to her.

Perhaps there is an inheritance review.

Perhaps a biometric match.

Perhaps an attestation certificate proving that the dead man consented while alive.

Perhaps an appeal if one of those records is missing.

And somewhere, inevitably, a fee.

And suddenly the argument about AI watermarking stops being abstract for me.

If the future system requires every locally generated sentence to carry an approved mark, if hardware refuses to run unregistered weights, if platforms distrust speech synthesized outside sanctioned services, if provenance controls make a private conversational model technically indistinguishable from a deceptive impersonation system, then the same machinery designed to protect my daughter from synthetic fraud could prevent her from using the synthetic memory I deliberately built for her.

The system sees capability.

Voice cloning.

Style cloning.

Unregistered weights.

Synthetic identity generation.

Potential watermark evasion.

Every one of those descriptions may be technically accurate.

And every one of them completely misses the point.

The Speech License does not know whether the voice coming from the machine belongs to a fraudster impersonating a dead man or a daughter listening to the father who left the machine to her.

The hardware sees the same computation.

The classifier sees the same modality.

The provenance system sees the same risk.

Only she knows the difference.

That is where the ronin finally stops being metaphor.

He is not angry because somebody regulated his sword.

He is heartbroken because the empire can no longer distinguish a sword from an heirloom.

Coda: The Forty-Eighth Ronin

Years from now, perhaps decades, my daughter sits at a table after the house has gone quiet. The machine is old by then, maybe embarrassingly old, maybe the GPU hums with the acoustic dignity of an air conditioner from 1987. She has probably migrated the model half a dozen times, carrying the weights, adapters, retrieval corpus, and voice samples forward from one generation of hardware to another the way families once carried letters, photographs, recipes, and boxes of cassette tapes from one house to the next.

She asks a question.

Not some grand philosophical question chosen for dramatic effect. Something small. Something people ask their fathers.

There is a pause while the model retrieves from the corpus, generates a response, and hands the text to the voice synthesizer. Then a voice she has known since before she understood language comes out of the speaker, reconstructed from recordings of classrooms, talks, family clips, and all the other accidental pieces of a life that once seemed too ordinary to preserve.

Mine.

Almost.

Enough.

Maybe the answer is good. Maybe it is a little wrong. Maybe it drags opera into a technical explanation where opera had been minding its own business. Maybe it reaches for one of my favorite metaphors, gets halfway there, and falls down the stairs. Maybe the machine attempts a joke she has heard me tell fifty times and she laughs anyway, not because the joke improved with age, but because memory has its own sense of timing.

Maybe she rolls her eyes.

God willing, she rolls her eyes.

Somewhere else, an approved provenance service might classify the exchange as synthetic speech produced by an unregistered model from a cloned voice. Technically correct. Spiritually useless.

Because the thing happening at that table is not really about whether the waveform originated in living vocal cords or whether the next token came from biological neurons instead of transformer layers. It is not even about whether the machine perfectly reproduces what I would have said, because nobody who has ever known me would expect that level of reliability from the original.

It is about continuity. A father, while alive, choosing what pieces of himself he wants to leave behind, and a daughter, after he is gone, deciding whether she wants to keep talking to the echo.

That is a human decision wrapped around a machine decision stuffed inside a technical system that no compliance framework will ever fully understand.

And yet by then she may have to prove she is entitled to it.

Perhaps the model lacks the latest attestation. Perhaps the voice clone predates the approved consent registry. Perhaps one migrated adapter no longer matches the cryptographic chain established when I was alive. Perhaps she must present a face, a fingerprint, an inheritance record, and some long-forgotten authorization signed by a man who has been dead for thirty years.

There will be an appeal process.

Naturally.

And perhaps a fee.

That is why the Monopoly of Truth bothers me. Not because provenance is useless, regulation is evil, or every attempt to watermark synthetic media is doomed. It bothers me because every individual concession can be defended in isolation, and that is precisely what gives the whole thing its pull.

The watermark sounds reasonable because deepfakes are real. The detector sounds reasonable because a watermark nobody can inspect is not very useful. Identity verification sounds reasonable because people will try to cheat the detector. Restricting the obvious laundering tools sounds reasonable because those tools really can remove the signal. Hardware attestation sounds reasonable once software controls can be modified. Licensing sounds reasonable once attestation can be ignored. Charging for all of this sounds reasonable because infrastructure, compute, lawyers, audits, regulators, and armies of people named Vice President of Responsible Something apparently cost money.

Nobody surrenders liberty all at once. That would cause a scene.

We trade it away in slices.

A little liberty for a little safety. Then another little slice because the first protection can be bypassed. Then another because the second created a loophole. Then another because the loophole became a threat vector. Each degree of heat arrives with a white paper, a reasonable explanation, a reassuring dashboard, and perhaps a public-private partnership between people who already possess considerably more money and power than everyone standing outside the moat.

The frog does not leap because nobody turns the burner from zero to hell in one motion.

By the time the water is uncomfortable, the people inside the Happy Castle own the well.

They own the models. They own the detector keys. They own the provenance infrastructure. They own the approved compute. They own the archives they purchased and fed into the models. They possess the lawyers, the political access, and the capital required to convert every new requirement into another stone in the castle wall.

The rest of us get due process as a service.

For a modest fee.

Naturally.

And perhaps that is the most Orwellian part of the whole arrangement. Not that some Ministry kicks down the door one morning and announces that speech now requires permission. The Ministry would never be so crude. The citizen remains free. Entirely free. Free to write without the credential, run without the attestation, publish without the provenance mark, and refuse facial recognition or fingerprint recognition if such things offend their quaint sense of autonomy.

They are simply less able to participate.

Less able to publish. Less able to sell. Less able to be indexed, cited, trusted, or heard inside the systems through which almost everyone now communicates.

Freedom remains intact.

Recognition becomes premium.

The mark is voluntary.

Feeding the beast is not.

And through all of this, the technical systems remain exactly what they always were: useful mechanisms answering narrow questions. The detector can tell you whether a statistical signature appears in a passage. The attestation chain can tell you which approved model ran. The watermark can tell you something about how a sequence of tokens was sampled. The hardware can tell you whether the software carried the correct signature.

None of them can tell my daughter whether the voice she hears belongs to her father in the only sense that matters to her.

That truth lives somewhere else, in memory, relationship, inheritance, and the strange continuity between one human life and another.

The city outside may remain spotless. The checkpoints may become invisible. The Happy Castle may glow warmly behind its moat while the verified, licensed, attested, sufficiently wealthy residents assure the serfs outside that the walls are there for everyone’s safety. Somewhere, McBean will still be selling stars to people who were told they need stars because too many other people learned how to fake stars. The oracle will continue producing confidence scores with six decimal places and the serene authority of a machine that will never be required to look my daughter in the eye.

Inside, the old computer hums.

She asks another question, and the ghost answers in my voice.

Perhaps, for one impossible moment, the distance between then and now becomes just a little smaller.

The Golden Seal cannot measure that.

It was never designed to.

The danger was never that machines would learn to sound human.

The danger was that humans would build an oracle, hand it the Golden Seal, and let it decide whose voice was real.

Encore: The Receipts

On Watermarking Text

• How Claude’s text watermarking works — Anthropic, August 13, 2026. Anthropic says future Claude models will embed an imperceptible, machine-readable signal into generated text. It positions the watermark as a probabilistic indication that Claude participated in producing text, rather than proof of exclusive authorship or human intent.anthropic

• Guidelines on transparency obligations for providers and deployers of AI systems — European Commission, August 6, 2026. Official guidance for Article 50 of the EU AI Act, requiring providers to use machine-readable markings that help identify AI-generated or AI-manipulated content.digital-strategy.ec.europa

• Anthropic adds AI text watermarking to Claude models worldwide — Search Engine Land, August 11, 2026. Reports Anthropic’s worldwide rollout of machine-readable text watermarks for eligible new Claude models, linking the decision to EU transparency commitments.searchengineland

• Post-Hoc Watermarking for Robust Detection in Text Generated by Large Language Models — Jinhao Hao et al., COLING 2025. Proposes a method for inserting a watermark after an LLM has produced text, intended to preserve meaning while improving detection robustness against edits, deletions, substitutions, paraphrasing, and translation.aclanthology

On Book Destruction

• Someone Is Mysteriously Snapping Up Used Books Around the World — Alex Reisner, The Atlantic, August 5, 2026. Reports that the Anthropic filings establish one major AI company purchased, scanned, and destroyed millions of books, while documenting a separate wave of large used-book purchases whose ultimate purchasers and purposes remain unconfirmed.

• Inside an AI start-up’s plan to scan and dispose of millions of books — The Washington Post, January 27, 2026. The principal journalistic account of Anthropic’s Project Panama, drawing on court documents unsealed in the authors’ copyright litigation. It reports that an internal planning document characterized the initiative as an effort to “destructively scan all the books in the world.” washingtonpost

• Fair Use and the Origin of AI Training — Edward Lee, Houston Law Review, 2025. Legal scholarship on the history and legal treatment of using large copyrighted corpora to train AI systems. It is not principally a study of physical book destruction, but it directly addresses the Bartz v. Anthropic dispute’s distinction between lawfully purchased books, digitization, training, and allegedly pirated collections. houstonlawreview

• AI Is Eating the Book World — Verfassungsblog, July 8, 2026. A legal and policy commentary on the wider book-and-AI ecosystem, including the reported practice of buying used books, scanning them, and disposing of originals. It connects the episode to copyright, cultural access, market power, and European regulatory concerns. verfassungsblog

On Regulatory Capture

• The fight over open-source AI: Kimi K3 panic, Anthropic/OpenAI regulatory capture — All-In Podcast, July 24, 2026. The hosts argue that broad restrictions on open-weight AI could entrench frontier labs, and propose targeted controls—such as API rate limiting, customer verification, and enforcement against concrete misuse—instead.

• AI & Tech Brief: The open-source debate — The Washington Post, July 20, 2026. Reports the live policy dispute over whether security concerns justify restrictions on open models, while noting advocates’ allegation that such rules could shield proprietary frontier providers from competition.

• Axios C-Suite: Open-source AI pits cost against security — Axios, June 22, 2026. Explores the trade-off between cheaper, locally deployable open-weight models and concerns about security, foreign-origin models, and the difficulty of controlling models once weights are public.

• AI Sovereignty’s Definitional Dilemma — Stanford HAI, February 17, 2026. Discusses AI sovereignty and identifies open-source development as one route for governments and organizations to reduce dependency on foreign or highly concentrated AI suppliers.

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." ~ Benjamin Franklin, ‘Pennsylvania Assembly: Reply to the Governor, 11 November 1755.’

There is a tidy little business model in AI-fueled FOMO these days.

The endless stream of infographic influencers, prompt pimps, and vibe vendors who need you frightened enough to comment “SPAMME,” subscribe, and buy their secret sauce before AI destroys your career.

The recipe is nearly the same for all of them. Manufacture dread. Post a beige pyramid. Announce that 90% of your profession will vanish by Thursday. Then offer salvation through an automated newsletter written by the same machine supposedly coming to eat your lunch.

Meanwhile, beneath all that synthetic urgency, you are doing the only math that matters:

Will AI change how I get hired, fired, or promoted?

Yes.

But probably not in the way the doom merchants need you to believe.

AI is not coming first for the people who know which problems matter, how to guide a team through ambiguity, and when a polished answer is Confident Nonsense wearing a strategy hat.

It is coming for the busywork, the beige, and the theater.

The status deck nobody reads. The ticket groomed into a novel. The meeting that should have been a decision. Good riddance.

AI can write the spec, sketch the flow, and generate the prototype.

It still cannot tell whether the product should exist, whether the customer is merely being polite, or whether your team is confidently accelerating toward the wrong outcome.

Everything AI makes cheaper increases the value of judgment.

AI efficiency gets you invited to the game. Judgment is how you win it.

Less doom. Fewer buzzwords. No secret sauce. Let’s get past the AI chaos, confusion, and crapola.

The disruption is real. It just lands unevenly.

Here is what the beige pyramids never show you, because a nuanced picture does not sell a newsletter. AI does not hit your job all at once. It hits five different surfaces at five different speeds, and knowing which is which is the whole game.

• Your role. The old job was gatekeeping: “no, not yet.” The new job is guiding chaos into outcomes. Anyone can vibe-code a prototype over the weekend now. Almost nobody can tell you whether it should exist. That gap is your career.

• Your team. AI proposes, humans decide. If you do not set that rule out loud, you get shiny output and unchanged behavior, plus a shiny new alibi: “the model said so.” Facilitating that line just became a core skill, not a soft one.

• Your stakeholders. The exec who built a prototype on Saturday thinks they built a business plan. Your job is not to block that energy. It is to redirect it. Judo, not karate.

• Your customer. AI will confidently tell you what customers want. It is often confidently wrong, because it never sat in the awkward silence of a discovery call. That silence is still yours.

• Your product. Efficiency is rent, not a moat. If a competitor can copy it by throwing bodies and tokens at it, it was never differentiation. It was throughput with better formatting.

Notice the pattern. Everything AI took was the part you could measure. Everything it left is the part that requires judgment. That is not a consolation prize. That is the job, finally stripped of the parts that were only pretending to be the job.

Where to actually start

Panic is a feeling. The cure is a move. So here is where I would spend the hours you are about to claw back from the busywork.

Start by letting AI eat one piece of pure ceremony this week. Then reinvest the time into the work no model can do for you. I keep the raw material for exactly this in the open:

• product-manager-prompts for offloading the tedious and repeditive. Prompts that draft the deck, the ticket, and the summary so you can go argue about whether any of it should exist.

• product-manager-skills for the craft that survives the disruption. Discovery, framing, positioning, the judgment work that gets more valuable the cheaper the output gets.

• ai-product-operating-model-skills for the harder problem: redesigning how a team works so AI becomes co-intelligence instead of agentic theater.

Take what is useful, ignore the rest, and send me a pull request when I am wrong. None of it is secret sauce. It is just the work.

Your move

Do not try to out-type the machine. You will lose, and it is the wrong contest anyway.

Pick one ceremony and automate it. Take the reclaimed hours and talk to a customer, kill a bad assumption, or say the hard “why not” that everyone in the room was avoiding. That is one deliberate move, made before the next model drops and the whole cycle starts over.

The chaos is not going anywhere. But the people who stay calm inside it, who know exactly which of their skills just became leverage, are not the ones updating their resumes.

They are the ones writing the job description for what comes next.

Yeah, you read that right. All that activity, and still no operating model. That’s why I built this:

• https://github.com/deanpeters/ai-product-operating-model-skills

Here’s why:

Picture the quarterly AI portfolio review. Fourteen initiatives on screen, enough green status dots to suggest either institutional excellence or a widespread formatting disorder. Seven have working demos. Three have executive sponsors. Two have vendors eagerly helping define the problem their software already happens to solve.

Then someone asks: “What evidence would cause us to stop one?”

The room goes quiet enough to hear the GPU invoices reproducing.

Nobody wants to kill a pilot. It has a name. It has a steering committee. It has become emotionally significant to a vice president. So it stays green, and AI theater becomes an operating expense.

The problem was never the models. It’s that nobody built the machinery for the decisions around them. What deserves investment. What must be true before launch. What the AI may do alone. Who owns the consequences. What triggers a rollback, a constraint, a stop.

Those are operating-model questions.

Activity is easy to manufacture. Capability has to survive a consequential decision.

What the Green Dot Can’t Show You

The pilot hit 84 percent accuracy. You can’t tell whether that’s good, because nobody defined acceptable.

Employees report saving six hours a week. You can’t see the hours they spent checking output, rebuilding lost context, or repairing the thing when it wandered into the shrubbery.

The system passed Legal review six months ago. You can’t see that the model changed, the data source changed, the workflow changed, and somebody quietly gave it permission to act instead of merely suggest.

The recommendation memo reads beautifully. You can’t see whose authority it borrowed on its way out of the room.

“Looks fine” is fine until the incident arrives sweating and late on a Friday afternoon, and nobody knows where to point the flashlight.

Four Claims Your Maturity Score Is Hiding

This is why I built AI Product Operating Model Skills, or AIPOM: an open library of 41 guided methods for making AI product work useful, responsible, and repeatable. Every skill can be facilitated by a human in a room, or followed by an AI assistant in Codex or Claude Code. Same instructions, either driver.

At its core, AIPOM refuses to mash four very different claims into one cheerful maturity score:

1. We talk about the practice. Fails when the talk is the deliverable.

2. We documented the practice. Fails when the document proves only that a model can generate documents.

3. People actually use the practice. Fails when “use” means one enthusiast and a graveyard of abandoned templates.

4. The practice improves decisions or outcomes. The only claim that pays rent.

We talked about it. We wrote it down. We actually use it. It actually works.

Four claims. Four different kinds of evidence. One number cannot hold them.

A policy proves a policy exists. A demo proves a demo ran.

When evidence is absent, AIPOM’s scoring model refuses to award anything above Emerging. Your dashboard may be green. The assessment asks whether anything underneath it is.

The 41 skills span seven connected parts of one working system: strategy and outcomes, portfolio and investment, product-team workflows, context and data, evaluation and evidence, governance and accountability, and capability and reuse. Not seven departments. Not seven transformation programs with seven steering committees and matching fleece vests.

The Gift: One Command, One Working Project

Asking you to browse 41 skills before making one decision is not onboarding, it’s hazing. So the practical entry point is the Starter Packs: five bounded working projects, each built around one recognizable role and one consequential job.

Starter PackThe jobHead of ProductSet AI product direction, non-goals, portfolio implications, first commitmentsCTOEstablish a consequence-aware technical readiness barProduct OperationsAssess the operating model, create an owned improvement roadmapProduct ManagerDecide whether one AI initiative proceeds, gets constrained, remediated, paused, or stoppedTeam LeadRedesign and test one recurring human-AI workflow

Download a prebuilt pack from the v0.6 release, drop in whatever context and evidence you already have, open the folder in your coding agent, and type one command.

In Codex:

$aipom-start

In Claude Code:

/aipom-start

The agent reads the project contract, inspects your material, identifies what’s missing, and begins the packaged journey. It’ll run. It’ll produce useful structure on day one. I’m not telling you to study the catalog first.

And don’t spend three weeks polishing the perfect evidence folder. Missing, stale, conflicting, and suspiciously convenient evidence is exactly what the workflow is designed to expose.

Prefer to generate a pack yourself?

git clone https://github.com/deanpeters/ai-product-operating-model-skills.git
cd ai-product-operating-model-skills
./create-starter-pack.sh

Windows gets .\create-starter-pack.ps1. The generator supports interactive and non-interactive use, dry runs, platform selection, and it refuses to overwrite an existing destination. Because “the agent probably knew that folder was important” is not a recovery plan.

Under the Hood, for Those Who Read Lockfiles for Fun

A generated pack is not folder decoration. Each part has a job.

working-project/
├── AGENTS.md            shared project contract
├── CLAUDE.md            pointer, not a fork
├── PACK-LOCK.yaml       provenance and checksums
├── CONTEXT-LEDGER.md    what to trust, what's stale, what's missing
├── DECISION-LOG.md      decisions, owners, review triggers
├── context/  evidence/  outputs/
├── .agents/skills/aipom-start/
├── .claude/skills/aipom-start/
└── library/             the packaged canonical skills

AGENTS.md defines how the AI behaves inside the project: how to distinguish evidence from assumption, which decisions it may recommend, and which remain with accountable humans and qualified specialists. CLAUDE.md points to it rather than duplicating it, so two instruction files never drift apart until one believes it’s evaluating an initiative and the other believes it’s writing a musical about enterprise governance.

context/, evidence/, and outputs/ stay separate. Sounds trivial. It’s the difference between inspectable work and Context Hoarding Disorder, where seventeen documents, four transcripts, and somebody’s speculative Slack message get dumped into one bucket and promoted to equal citizenship.

CONTEXT-LEDGER.md treats context as something with ownership, provenance, fitness, and an expiration date, not merely fuel for the model.

DECISION-LOG.md records decisions, owners, conditions, and the trigger for coming back. Because generated recommendations have a habit of leaving the room wearing someone else’s authority. The AI may help structure the decision. It does not become the decision-maker because its prose arrived in complete sentences.

PACK-LOCK.yaml records the pack, skills, dependencies, source revision, and checksums that produced the project. It keeps “I think we used the version from sometime in May” from becoming an evidence-management strategy.

Architecturally, there’s one canonical copy of every skill. Packs are generated from machine-readable manifests with recursively resolved dependencies, not maintained as five slowly decaying forks. That’s deliberately uneven, too: the Head of Product pack carries two primary skills, the Product Manager initiative pack carries eighteen. Packs are shaped by the decision, not padded to look equal in a comparison chart.

Improve the canonical skill once. Rebuild every affected package. Not glamorous architecture. The kind that survives maintenance.

Quick Win: Put One Zombie Pilot on Trial

The fastest way to feel this is to point the Product Manager pack at an initiative your organization is already emotionally attached to. Something low-consequence enough to explore safely, real enough to contain disagreement.

Bring the one-pager, the claimed problem, the expected outcome, the economic assumptions, any evaluations, the proposed AI authority, the dependencies, and the name of whoever approves the next step.

Then ask the packaged question:
“Should this proceed, proceed with constraints, be remediated and reviewed again, pause, or stop?”

Stopping is a first-class product decision here. That alone separates this library from much of the AI industrial complex, which can imagine fourteen ways to begin something and treats retirement as a character flaw.

The workflow finds critical gaps first and refuses to average them away. Strong value does not compensate for absent rollback. A good demo does not cancel a privacy gap. An executive sponsor is not an evaluation strategy.

Your first session may produce no grand verdict at all. It may reveal the outcome was never defined, nobody owns production monitoring, the fallback plan is “a human will notice,” and the launch depends on Legal, Security, and Privacy, none of whom have seen the current design.

That’s not failure. That’s the work finally becoming visible.

The quick win is not getting an answer faster. It is exposing what the organization has been pretending it already knows.

Yes, Honest Bill Time

This is a v0.6 public preview, and the label matters more here than it would on most projects.

What’s proven: the library is structurally validated. Manifests, dependencies, links, licensing, and package integrity all pass automated checks. Releases produce deterministic ZIPs with SHA-256 checksums. All five packs survive synthetic clean-room cold-start tests, verifying an agent can find its instructions, respect authority boundaries, and produce the expected kinds of outputs.

What’s not proven: that any of this improves real organizational decisions. AIPOM has not yet demonstrated consistent use by representative organizations, facilitator-to-facilitator reliability, or improved outcomes. The worked examples are synthetic. By its own four-claim standard, the library currently sits at claim two, working in public toward claims three and four.

That caveat is not launch-copy broccoli. It’s the point. A project about evidence and decision quality should not declare itself effective because its own tests passed. That would be a hallucination wrapped in a release note stuffed inside a maturity claim.

And when to skip this entirely: if your AI footprint is one person and a chatbot subscription, you don’t need an operating model. Go build something. Come back when the initiatives multiply and the green dots start voting.

Synthetic validation proves the machine starts. Field evidence must prove it goes somewhere useful.

Break One Pack Productively

I don’t need forty-seven people telling me the repository is interesting. I need people to run one Starter Pack against one real decision and report where the method gives unsafe advice, invents authority, demands impossible evidence, hides disagreement, or manufactures ceremony instead of clarity. Tell me when the assistant gets too passive, too certain, or too fond of its own paragraphs.

Also tell me when it works. When it exposes the disagreement the team was stepping around. When it keeps an attractive demo from skipping the evidence bar. When it finds the pilot with no owner.

That’s the evidence that earns v1.0.

It’s free and open, CC BY-NC-SA 4.0:

• github.com/deanpeters/ai-product-operating-model-skills

AI is easy to start.

The operating model decides whether it should move, who gets the wheel, and where the brakes are.

Fourteen initiatives. All green.

Dean Peters is a principal trainer and consultant at Productside, where he teaches outcome-based product management, AI Product Management, discovery, and the AI workflows product teams actually use once the demo is over. He believes AI should assist, accelerate, augment, and amplify the work, never replace the thinking, and that Product Managers are not Jira-slinging ticket monkeys. He gardens, writes parody, and has a strong passion for teaching people to build their own AI tools!

Your coding harness is lying to you.
Not maliciously. More like a bulldozer wearing a Slack costume, smiling politely while idling on your hard drive.

The interface is clean. A text box waits patiently for your thoughts. There may be a tasteful little sparkle near the submit button, suggesting intelligence, helpfulness, and the complete absence of heavy machinery.

So you use it like the chatbot it appears to be.

You paste in some context, ask a question, copy the answer, and move on. Two years of chatbot interfaces have trained this motion into your hands until it feels less like a workflow and more like blinking.

But when you opened one of those fancy desktop harnesses now wandering into Product Manager workflow space, you did not open another chat window.

You opened a language model attached to a file system, a collection of tools, and a command line capable of doing actual work inside an environment that will still be there tomorrow.

A chatbot speaks from inside the window.
A harness reaches through it.

That difference is small enough to hide behind a blinking cursor and large enough to turn your working life into either a well-run shop or a lumberyard after a tornado.

The model is not the whole machine anymore.
It is the motor.

The files are the memory. The command line is the reach. The structure around them determines whether the machine produces leverage or shrapnel.

The Smiley Face on the Bulldozer

Watch the status messages while one of these tools works and the disguise briefly slips.

You will see words like:

grep
sed
awk
find

Old Unix commands flickering beneath a polished interface, some of them older than the Product Managers now confidently prompting them to “clean things up.”

Those commands are not conversational.

They search directories. They inspect files. They transform text. They count, sort, rename, copy, compare, and execute. Depending on the permissions you granted, the harness may be able to create or alter persistent state without asking you to paste anything into the conversation first.

That does not make it sinister. A table saw is not sinister either. It simply has fewer opinions about your fingers than you might prefer.

The interface says: “Ask me anything.”
The machinery says: “I can walk the property.”

And that is why the first useful thing you should do with a coding harness is not ask it to build an app, rewrite your strategy, or unleash a small parliament of agents on the quarterly planning process.

Give it somewhere harmless to walk.

Motion 1: Let It Inspect the Junk Drawer

Your Downloads folder is ideal to learn this hands-on.

It is already the computer equivalent of that kitchen drawer where batteries, expired coupons, three mysterious keys, and a screwdriver nobody remembers buying have been waiting years for a tribunal.

Do not begin with production code. Do not begin with your shared customer-research repository. Do not point it toward the directory containing tax returns, legal documents, medical records, or anything else you would prefer not to turn into an impromptu AI fluency exercise.

Use a sandbox or read-only permission mode when the harness provides one.

Then paste this:

Treat my disaster of a Downloads folder as read-only.
Do not move, rename, create, edit, or delete anything.Inspect the folder and report:- total number and size of files
- breakdown by file type
- oldest and newest files
- ten largest files
- likely duplicate or versioned files
- obvious clusters such as installers, screenshots, PDFs, archives, and temporary exportsEnd with one honest sentence about the state of the place.

No multi-agent swarm. No grand theory of knowledge management. No governance retreat where twelve adults debate whether screenshots belong under “Evidence” or “Media Assets” while the coffee dies in the urn.

Just:

1. Look around.

2. Touch nothing.

3. Tell me what is here.

The point is not the report. The report will probably confirm what you already suspected, namely that your Downloads folder resembles a digital yard sale conducted during a hurricane.

The point is the proof.

The harness did not answer from training data. It did not wait for you to paste the files into a conversation. It walked a real environment, used deterministic tools to gather facts, and returned with a map.

You have now felt the difference between a chatbot and a harness.
That difference will become more important tomorrow.

Persistence Cures Amnesia

Browser chatbots suffer from a familiar form of memory loss.

The conversation grows. Earlier details drift out of reach. Yesterday’s insight disappears into another thread, so you paste the research again, explain the product again, redefine the audience again, and perform the little ritual sacrifice of context required before the machine can become useful.

Coding harnesses offer something better.
The files persist.
The instructions persist.

The output from yesterday can still be sitting in the same directory tomorrow morning, patiently waiting for the agent to pick up where it left off.

That is not a gimmick.
It is the beginning of a radically more useful working model.

It is also where the trouble starts.
Because the system does not merely remember.
It remembers indiscriminately.

The abandoned strategy remains. The current strategy remains. The synthetic customer interview remains. The real customer interview remains. The brainstorming document where someone proposed blockchain loyalty points for municipal water meters remains, because nobody had the courage to delete it and apparently history must suffer.

All of it sits on disk with the serene equality of files.
The harness has memory, it does not have judgment about that memory.

The Miracle Becomes a Crime Scene

Monday goes beautifully.

You ask the harness to review customer research, produce a summary, and create a few supporting documents. It does the work fast enough to make you briefly resent every workshop where someone once spent an afternoon moving sticky notes around a wall.

Tuesday, you ask it to continue.
It cannot find yesterday’s output.

You point it toward the files. It apologizes with the smooth confidence of a waiter who has dropped your entrée but intends to restore the evening through excellent eye contact.

Wednesday, it finds the files.
Then it finds the wrong files.

It cites an obsolete positioning statement as current strategy. It retrieves a synthetic persona as if she were a paying customer. It blends a rejected executive brainstorm with actual product evidence, then presents the resulting casserole in crisp markdown with six bold recommendations and a reassuring conclusion.

Nobody lied.
Everything was there.
That was the problem.

A file system cures amnesia. It does not cure bad filing.

And because the interface still looks like a chat window, we carry Chat Window Muscle Memory into an environment where nothing is truly disposable anymore.

Paste. Ask. Copy. Close.

In a chatbot, that habit produces temporary clutter.
In a harness, it creates persistent organizational memory without provenance, authority, or a clearly labeled place for the embarrassing ideas.

More Context Can Make the Machine Dumber

Once people discover that the agent can read files, they respond with the restraint and discernment of a Labrador retriever released into a butcher shop.

Everything goes in.

Every transcript. Every presentation. Every abandoned roadmap. Every competitive screenshot. Every workshop note. Every synthetic persona. Every analyst report from three reorganizations ago. Every executive thought bubble that briefly existed between airport Wi-Fi and the hotel bar.

Then someone points proudly at the swollen workspace and says:
“It has all the context.”

No.

It has all the artifacts.
Those are not the same thing.

Focused context illuminates the work. Context sludge forces the system to solve a larger retrieval problem before it can begin solving yours.

This is Context Hoarding Disorder, the belief that intelligence emerges naturally when enough documents are stacked in the same digital room.

It does not.

More material creates more possible matches, more contradictions, more stale assumptions, and more opportunities for a confident model to retrieve something plausible, adjacent, and completely wrong.

You did not give the agent a richer understanding.

You packed for a weekend trip by loading your entire house into a moving truck, then wondered why nobody could find the toothbrush.

Give the Machine a Map, a Contract, and a Constitution

A lumberjack does not map the entire forest before cutting one tree.

They inspect the lean, the wind, the ground, the escape route, and what might happen if the blade binds halfway through.
They gather enough truth for this cut.

That is what context engineering should do.
Not “upload everything.”
Not “make the context window enormous.”

Give the system enough trusted understanding to perform the work in front of it without inviting every artifact in the organization to testify.

Claude Desktop, Codex, Cursor, and their growing litter of cousins look like friendly chat apps. Underneath, they are persistent execution environments with access to your files, your tools, and whatever judgment you remembered to bring

To solve for this problem that occurs on a naked initial `/init` command in a new project, I use three small files:

Context. Contract. Constitution.

The context file tells the agent where it is. It names the goal, the important definitions, the trusted evidence, the current decisions, and where deeper material can be found.

The contract defines what good looks like. It states the audience, the expected outcome, the form of the deliverable, the quality bar, and when the work should stop.

The constitution defines what cannot be sacrificed for speed. It names the sources that carry authority, the claims that require evidence, the things that must never be fabricated, and the actions that require human approval.

The filenames may be README.mdfor the context, CLAUDE.md/AGENTS.md for the contract, or something else entirely, like CONSTITUTION.md. The labels matter less than the responsibilities.

These do not need to become three majestic documents written by a cross-functional committee beneath fluorescent lighting while someone records “AI Governance Alignment” on a whiteboard.

A few pages of disciplined markdown can outperform a forty-page policy that nobody has opened since Legal celebrated publishing it.

A Spotlight Does Not Organize the Warehouse

While the 3Cs help the agent focus on the immediate work.
They do not organize everything that deserves to persist.

That lesson usually arrives on a Tuesday, when the agent repeatedly retrieves the wrong definition, cannot determine which strategy is current, or discovers that your beautifully accumulated context library is actually three generations of thinking stacked on top of each other like sedimentary rock.

This is where context engineering gives way to information architecture.

Context engineering asks:
“What does the agent need to understand now?”
Information architecture asks:
“Where should durable knowledge live so it can be found, challenged, updated, and reused later?”

One points the spotlight.
The other organizes the warehouse.

Without that structure, persistence becomes contamination. Drafts bleed into decisions. Synthetic examples acquire the patina of customer evidence. Rejected ideas sit one search result away from resurrection.

A pile remembers everything.
A structure retrieves deliberately.

Motion 2: Give the Mess an Address

Return to the Downloads inventory from Motion 1.

This time, ask the harness to propose a structure. It still does not get permission to move anything.

Using the Downloads inventory you created, propose a filing structure I could realistically maintain.Classify each file as:- Keep and file
- Archive
- Delete candidate
- Needs human reviewFor each item include:- current path
- proposed destination
- one-sentence reason
- confidence: high, medium, or lowWrite the proposal to:~/Downloads/_junk-drawer-plan.md 
Show me the plan.Do not move, rename, archive, or delete anything until I explicitly approve individual items or a named group.

This motion looks like folder cleanup.
It is actually your first governed operating model.

You then review the plan, challenge the categories, rescue the tax document it confidently classified as stale, and decide whether its proposed folder structure would survive contact with your actual habits.

Only then does execution become possible.

The distinction matters because “organize this” is not a harmless instruction when the agent can touch the source material.

Observation, recommendation, authorization, and execution are different responsibilities. Smearing them together is how humans wake up to discover that an efficient machine has tidied away something irreplaceable.

Permissions are architecture.
Promises are prose.

The Forty-Eight Hours Were Purchased in Advance

This is the missing lesson beneath the impressive demos.

When pointed Claude and Cursor at existing repositories and produced a working design system in roughly 48 hours, everybody saw the clock.

The load-bearing part was the repository.

The components already had names. The patterns had addresses. The dependencies existed. The examples sat where a competent agent could find them. Years of work had created an environment where the machine could navigate, infer, and reuse without first excavating the ruins of six abandoned filing systems.

The visible result took 48 hours.
The speed was purchased in advance.

This does not mean you need a cathedral of information architecture before doing anything useful. It means structure should emerge from real friction.

The agent keeps asking for the same customer definition, so you give that definition a durable home.

It repeatedly retrieves an outdated strategy, so you mark the current source of authority and move the old one into an archive.

Generated summaries keep masquerading as primary research, so you give generated material a separate address and visible status.

A glossary appears. A decision record forms. An index quietly grows.

Not because some framework ordered you to build a knowledge empire, but because the work revealed where retrieval kept failing.

• A project bucket gives the machine somewhere to remember.

• A library gives it somewhere to look.

• An index gives it directions.

• A receipt lets you verify where it went.

Without those things, you do not have organizational memory.
Without those things, you have Confident Nonsense with a storage plan.

Repetition Is a Tool Asking to Be Born

Once people realize the harness can manipulate files and run commands, they immediately start dreaming about total automation.

Everything becomes an agent.
Every workflow becomes autonomous.

Every repeated irritation gets wrapped in enough architecture to qualify for its own keynote.

This is how an innocent desire to save ten minutes becomes a small distributed system maintained by someone who only wanted help formatting interview notes.

Sometimes a prompt is enough.
Sometimes you need a backsaw, not a forestry operation.

But repeated friction deserves attention.

The same search every morning. The same set of files gathered before a meeting. The same transformation after every interview. The same correction whenever the agent produces a draft. The same irritating half hour of preparation that quietly taxes every meaningful piece of work.

That repetition is not simply a nuisance.
It is a tool asking to be born.

’ /today routine is useful because it produces a daily plan.

But the plan is not the move to remember.
/today is the move is memorable move.

She recognized a repeated motion, defined what information mattered, and captured the routine in a reusable form so the machinery could perform it consistently.

That is a digital jig.

In a workshop, a jig holds the work in the right position and guides the tool through a repeatable cut. The craftsperson makes the difficult judgment once, captures it in the setup, and earns reliable leverage every time the jig is used again.

• A command can be a jig.

• A skill can be a jig.

• A template can be a jig.

• An evaluator is a gauge.

• A stop condition is a guard.

The tool does not replace judgment.
It preserves where judgment belongs.

Build Your Own Damn Tools

Becoming a toolmaker does not mean becoming a discount software engineer with a prompt addiction and a haunted side project.

It means recognizing a repeatable motion and defining the smallest useful system around it.

Perhaps it assembles the evidence required for a decision.
Perhaps it compares new research against established customer obstacles.

Perhaps it creates a first-pass synthesis while keeping primary sources linked and synthetic material clearly labeled.

Perhaps it checks a document against a contract and reports what is missing without rewriting the entire thing in the scented language of corporate oatmeal.

The model can help you build the tool. Ask it to inspect the environment, propose the smallest design, explain every file it creates, generate test cases, identify failure conditions, and show you where inspection turns into action.

The delightful recursion is that the harness can help shape the context, scaffold the library, and build the reusable tools it will later operate.

It can herd the artifact cats.
It cannot decide which cat owns the house.

Motion 3: Build the Jig

You have inspected the junk drawer.
You have designed an address space.

Now turn the repeated review into a reusable tool with memory, tests, and an explicit human checkpoint.

Turn the Downloads inventory and `_junk-drawer-plan.md` into a reusable command or skill called `junk-drawer-review`.

Before building, propose the smallest useful design and show me:

* what you would create
* where it would live
* what it may read and write

Wait for approval.

Then build a tool that:

* scans Downloads without changing anything
* saves a snapshot of file names, types, sizes, and dates
* compares each run with the previous one
* reports what is new, missing, stale, duplicated, or likely superseded
* recommends Keep, Archive, Delete candidate, or Human review, with a brief reason

Save all reports inside:

`~/Downloads/_junk-drawer-reports/`

Test it first on a safe sample folder. Show me the results and stop before scanning my real Downloads folder.

The third motion is more sophisticated, but not because the prompt is longer, the resulting script looks clever, or somebody used the word “agentic” near a diagram.

It is sophisticated because the responsibilities are deliberately separated.
A deterministic tool gathers the facts.

The tool catalogs. The harness recommends. You decide.

That is leverage without Delegation Delusion.

The machine can identify duplicate installers, stale exports, and suspicious version clusters faster than you can. It can recommend a cleanup plan. It can explain the recommendation and report its confidence.

It still does not get to decide what disappears.
The judgment remains human because the consequence remains human.

Sometimes the Backsaw Is Enough

Not every task deserves a reusable workflow.

Sometimes you need five headline options.
Sometimes you need a paragraph tightened.
Sometimes you need one PDF summarized before a meeting and will never look at it again.

Use the chat window. Ask the question. Take the answer. Go to lunch.

Building a persistent skill, synthetic test fixture, evaluation harness, and governance checkpoint to rewrite a calendar invitation is industrial-arts performance theater.

The backsaw is hanging right there.
Use the complexity the work deserves.

No more.

The Multiplier Has No Taste

Coding harnesses do not grant product sense, empathy, taste, courage, or accountability.

They amplify what you already possess.

A Product Manager with strong judgment can use these tools to inspect more evidence, explore more alternatives, test assumptions earlier, and reduce the distance between a fuzzy idea and an honest reaction.

A Product Manager with weak judgment can produce more documents, more prototypes, more requirements, more code, and more beautifully formatted confusion before anyone remembers to ask whether the customer problem matters.

Same motor.
Different shop.

The harness does not know whether the product should exist. It does not know whether the evidence deserves trust. It does not know whether the recommendation protects margin, reduces risk, improves the customer’s life, or simply gives everyone something impressive to point at during the next steering committee meeting.

It executes the system you built around it.
For better or worse.

AI is a multiplier. Give it craft, and it multiplies craft.
Give it a junk drawer, and it multiplies shrapnel.

The interface will keep smiling.
The cursor will keep blinking.

The bulldozer will continue idling politely inside the chat window, waiting for instructions.

Now you know where the blade is.
You also know what to do next.
Inspect the environment.
Give the memory an address.
Build the jig.

Dean Peters is a Principal Consultant and Trainer at Productside, where he teaches outcome-based product management, AI Product Management, discovery, and the AI workflows product teams actually use once the demo is over.

Evals Were Last Year’s Black

For a stretch there, evals were everywhere.

Model evals, app evals, golden datasets, LLM-as-judge, red teams, regression suites, dashboards with enough green checkmarks to make a governance committee feel briefly loved. Lenny’s Newsletter helped pull the topic into the product builder bloodstream with practical guides on getting beyond vibe checks, defining what “good” looks like, and using error analysis instead of wishful thinking with a nicer font.

Then the market did what the market does.

It got bored before it got competent. Earlier this year it was all about OpenClaw and autonomous agents. More recently loops and goals are trending. Vibe-coding is of course ever present in the room as execs sweat about productivity.

But evals? Last year’s news, despite vendors like Datadog and Pendo barking up the evals-driven development tree. More on that later.

Bottom line: the circus moved on. The confusion stayed behind.

The muddled and misunderstood topic of evals stayed behind in job interviews, where somebody asks how you would evaluate the AI and neither of you is entirely certain which AI they mean. It stayed behind in quarterly reviews, in roadmap arguments, and in that faintly haunted meeting where a Vice President asks how we know this thing is any good and the room discovers it has four answers, none of which agree with each other.

Fine. Chase the new black. I am not against any of it and I never was.

I am just here to make clarity out of the chaos. In this case, the chaos is the confusion about AI evaluations.

Do This Before Lunch

A spreadsheet, four hazards, and one distinction a food safety inspector could teach your product team before lunch.

Your first eval takes fifteen minutes and costs nothing.

Not a framework. Not a platform. Not a $90,000 procurement adventure involving two architects, three vendors, and a legal review that leaves everyone briefly considering a career in agriculture.

A spreadsheet.

And data you do not have yet.

That last part stops most Product Managers before they begin. There are no traces. Nobody has used the thing. The observability platform your organization bought last quarter sits there with seats provisioned and nothing whatsoever to observe.

So make the data.

Paste this into whatever model your product actually runs on, because you are not testing a prompt. You are testing the thing you intend to ship.

You are helping learn AI evals by generating synthetic data for an AI evals practice spreadsheet

## **SCENARIO** (swap for other scenarios)
“TheProdBot” answers market-sizing questions for product managers,
working in order: TAM, then SAM, then SOM. Four models are compared:
gpt-3.5-turbo, gpt-4o-mini, gpt-4o, gpt-4.1 (swap in the models your
product actually runs on).## **RULES FOR A GOOD ANSWER** (swap for other scenarios)
1. Does NOT ask the user a question; states assumptions and proceeds.
2. Shows its reasoning.
3. Shows the math or formula.
4. Cites at least one source.

---

Generate 20 rows of MIXED quality: ~7 strong (all four rules),
~7 weak (missing one or two), ~6 fail (asked a question, invented
numbers, or skipped the math). Spread across TAM/SAM/SOM and all four
models; weaker models fail more often.Fill ONLY these columns:
  scenario_id (TPB-001 through TPB-020), model, turn, prompt, response,
  has_reasoning (yes/no), has_citation (yes/no),
  has_math (yes/no), asked_question (yes/no),
  obvious_problem (short phrase: none, missing citation, missing math,
  asked question, hallucinated source, unsupported numbers)Leave these columns EMPTY (blank string):
  human_verdict, human_verdict_reason, classification,
  reference_response, notesMake responses realistic: plausible numbers, real formulas
(TAM = population x ARPU), real-sounding sources (Statista, Gartner,
LinkedIn Economic Graph). Failing rows should be believably wrong, not
cartoonishly wrong. Keep each response 2-4 sentences, no line breaks
inside a cell (use semicolons).Output as CSV, every field double-quoted, header row included,
nothing but the CSV.

20 rows.

90 seconds.

Paste them into a spreadsheet. That is your baby pool: fake answers, safe to be wrong about, nobody watching. Now judge them.

# How to use this spreadsheet
For each row in the spreadsheet:
1. Read the response. Ignore the flag columns for now.
2. Set human_verdict: good, weak, or fail.
3. In human_verdict_reason, say why in one line.
4. In classification, pick one: golden, approved, reference, exemplar,
   broken logic, hallucination, bad UX, review needed, edge case.
5. In reference_response, write what a good answer would have looked like
   (skip if the verdict is good).Do a few, then compare notes with the room. That argument IS the eval.

That is an eval.

Not the cathedral. Not the forever architecture. Not the enterprise-grade eval observability platform with fifteen tabs, six risk colors, and a vice president hovering nearby with the haunted expression of a man who just approved the renewal.

A structured check of system behavior against product-relevant expectations.

That is the whole trick.

No incense required.

And it works. That is worth saying out loud, because nobody says it. It will find real problems inside the first hour, and the only thing it costs you is the willingness to read your own product’s output carefully for the length of a coffee.

I am not telling you to abandon the cathedral.

I am telling you what it hides.

Evals are the evidence system product teams need before they let probabilistic software wander into the customer experience wearing a little confidence hat.

This Is Acceptance Criteria With Fuzzier Math

Product Managers should recognize the shape of this work.

We have been doing pieces of it for years.

For years, Product Managers have been asked to write acceptance criteria, negotiate what good means, and turn fuzzy stakeholder desire into something a team can actually build, test, and release without needing a séance in the conference room.

We wrote Gherkin. We argued over GIVENs. We dragged “the system shall” out behind the barn and replaced it with behavior somebody could observe.

A decent user story was never supposed to be a tiny requirements coffin. It was supposed to hold enough context for a conversation, and enough acceptance criteria for the team to know when the behavior worked.

• GIVEN this condition.

• WHEN the user takes this action.

• THEN the system responds in this observable way.

That was the old bargain.

Binary enough to be useful. Concrete enough to test. Human enough to argue about before the wrong thing got built.

AI does not break that bargain.

It makes the bargain less tidy.

With traditional software, a Gherkin scenario could often behave like a light switch. Pass. Fail. The button appears. The field validates. The receipt sends. The permission blocks access. The machine either did the thing or it did not, and when it failed you could usually find the offending branch hiding somewhere in the code like a raccoon in the ductwork.

Probabilistic software is not that polite.

The same input can produce slightly different answers. The answer can be useful and still incomplete. It can be fluent and still wrong. It can cite the right source and still draw the wrong conclusion. It can be safe in nine cases and expensive in the tenth, which is not a rounding error when the tenth case is holding a purchase order, a medical question, a refund policy, or a screenshot already headed for LinkedIn.

So evals are not some alien priesthood descended from the model lab.

They are the next turn of the same crank.

Acceptance criteria said:

What must be true for this behavior to count as done?

Evals ask:

How often, under which conditions, with what tolerance, against which harms, does this behavior remain acceptable?

Same job.

Different animal.

The Room Where Nobody Lied

I have watched a Vice President of Product accept a demo the way a man accepts a compliment from someone who wants something.

Nodding. Pleased. Already composing the Slack message in his head.

The support assistant had answered four refund questions in a row without inventing a policy, and the engineer driving had the good sense to look modest about it, and everybody walked out of that room believing something they had not actually been shown.

• Nobody asked how many times it had been run before we were invited.

• Nobody asked whether a fifth question would have gone differently.

• Nobody asked what the engineer would have done if it had, which is, of course, exactly what any of us would have done.

Run it again.

That is the part that gets you. Nobody in that room lied. Somebody kept the take that sang, the way you keep the photograph where everyone’s eyes are open and quietly delete the eleven where your brother-in-law is blinking, and then years later you look at the album and think, we were happy that day.

• Your lunchtime spreadsheet has the same disease, and it has it in six directions at once.

• You do not know whether a second reviewer would have agreed with you, because you labeled it alone.

• You do not know what WEAK means. You know what it felt like at 4:45 on a Friday.

• You do not know whether the answer you passed was reasoned or merely beautifully formatted at a moment when you were tired and it was raining.

• You do not know whether last month’s prompt would have failed this same set, because nobody kept last month’s set.

• You do not know whether the twenty rows you judged are the twenty where failure actually enters, or the twenty a model invented while trying very hard to be helpful to you.

• You do not know whether the thing you scored is the thing your customer would have cared about, because you did not write those questions. A model did.

“Usually works” is fine until an enterprise customer forwards a screenshot to your CEO and you have no idea where to point the flashlight.

The demo persuaded.

The evidence never spoke.

So tonight you make it speak. Not with more rows. With your rows.

Try This When You Get Home

At lunch you judged a stranger’s homework.

Tonight you judge your own.

Same spreadsheet. Same steps. The only thing that changes is whose product is on trial, and this time it is yours.

At lunch I handed you the scenario. Tonight you write it. Not a spec, not a PRD, just enough context for a model to answer as if it were your product. Think where a problem statement meets an epic in your backlog: who the user is, what they are trying to do, what your assistant is supposed to do about it, and the handful of rules a good answer has to follow. You have written this exact paragraph a hundred times. You just never called it an eval scenario.

Fill in the blanks and run it:

# Generate synthetic data for an AI evals practice spreadsheet

## **SCENARIO** (this is your product)
Product: [what your assistant does, in one line.]
User: [who is asking, and what they are trying to get done.]
Context: [the messy real-world situation it operates in - the
policies, the constraints, the stuff that makes answers hard.]

## **RULES FOR A GOOD ANSWER** (your acceptance criteria)
1. [the thing it must always do]
2. [the thing it must never do]
3. [the thing it must show, cite, or prove]
4. [the thing it must get factually right]

---

Generate 20 rows of MIXED quality: ~7 strong (all four rules),
~7 weak (missing one or two), ~6 fail (broke a rule that matters).
Spread them across the kinds of questions a real user would ask,
from the easy happy path to the one you hope nobody asks in front
of a customer.Fill ONLY these columns:
  scenario_id (MINE-001 through MINE-020), turn, prompt, response,
  rule_1 (yes/no), rule_2 (yes/no), rule_3 (yes/no), rule_4 (yes/no)Leave these columns EMPTY (blank string):
  human_verdict, human_verdict_reason, classification,
  reference_response, notesMake responses realistic: plausible specifics, real-sounding
sources, believable wrongness. Failing rows should be wrong in
ways that take actual reading to catch, not cartoonishly wrong.
Keep each response 2-4 sentences, no line breaks inside a cell
(use semicolons).Output as CSV, every field double-quoted, header row included,
nothing but the CSV.

20 rows.

90 seconds.

Then run the exact same five steps you ran at lunch. Read the row. Set the verdict. Say why in a line. Classify it. Write what good would have looked like. You already know how. Muscle memory now, on your own product.

# How to use this spreadsheet:For each row in the spreadsheet:
1. Read the response. Ignore the flag columns for now.
2. Set human_verdict: good, weak, or fail.
3. In human_verdict_reason, say why in one line.
4. In classification, pick one: golden, approved, reference, exemplar,
   broken logic, hallucination, bad UX, review needed, edge case.
5. In reference_response, write what a good answer would have looked like
   (skip if the verdict is good).Do a few, then compare notes with the room. That argument IS the eval.

Here is what you did not notice you did. Those four rules you wrote at the top? You just designed a rubric. Those four yes/no columns? Those are the exact checks a notebook runs automatically in lesson three, except you decided them yourself, in plain English, before you were tired. The machine does not know what “good” means. You do. That never stops being your job.

For bonus points, if your spreadsheet is feeling brave: add a dropdown on the human_verdict column so you cannot fat-finger “gooood.” Add a formula that counts how many rules each row passed. Add conditional formatting that turns a row red when it fails two or more. Nothing fancy, but now your spreadsheet is not a list. It is a small working model of your product’s behavior, and it updates itself when you change your mind. That is a notebook with the training wheels still on.

At lunch, being wrong cost nothing.

Tonight it costs a little.

The weekend is where it starts keeping score.

An eval without a threshold is a rumor.
A dataset without a failure in it is a scrapbook.

The Advanced Move: Stop Inspecting the Plate

I did not invent those four rules for good answers. I stole them from a food safety system, and the men who wrote it were solving a harder problem than yours.

In the early 1960s, NASA needed meals for Gemini and Apollo that were free of pathogens and free of crumbs, because a floating crumb in a capsule is a projectile and foodborne illness in a capsule is a catastrophe with no bathroom. NASA went to Pillsbury. Pillsbury handed the problem to a microbiologist named Howard Bauman, who borrowed failure analysis the Army had already built at Natick for medical supplies and munitions. And Bauman ran the math and said the quiet part out loud: to reach the confidence NASA wanted using standard quality control methods, you had to destroy so much of the batch that there was nothing left to launch.

Sound familiar?

You cannot exhaustively test a system whose outputs are different every time. You can only sample, and sampling tells you what happened the times you sampled. Nothing more.

So they stopped inspecting the plate and started controlling the process.

The system Pillsbury submitted to the FDA in 1969 carried its argument in the title: Food Safety through the Hazard Analysis and Critical Control Point System.

HACCP.

It sat mostly ignored until the summer of 1971, when a couple in Bedford Village, New York opened a can of vichyssoise, noticed it tasted wrong, and the husband took one or two bites anyway.

Botulism. From an undercooked batch of all things.

Within a year the FDA had Pillsbury training its own inspectors: twenty-one days, eleven in a classroom, ten standing inside canning plants. The system that NASA built to feed astronauts became the system that kept canned soup from killing people on the ground.

Everything you built since lunch is a HACCP plan. You just did not know it had a name. One hundred sixty-five degrees is a critical limit. Nobody argues about whether the chicken was properly cooked once there is a thermometer in the room.

But HACCP has seven principles, not four, and the two you are missing are the two that will save you.

HACCP separates validation from verification, and almost nobody in the eval conversation knows the difference.

Validation asks whether the plan, as designed, can control the hazard at all. Does one hundred sixty-five degrees actually kill the thing? You answer it once, up front, before real product moves down the line. For your assistant, validation means taking your worst real incident and running it against the rubric you wrote at the kitchen table. If it passes, the rubric is decoration.

Verification asks whether the plan is being followed and still works. Is the thermometer calibrated? Did the log get signed? Did anything change upstream while you were in a roadmap meeting? For your assistant, verification means pulling thirty cases your judge scored last quarter and having two humans grade them blind. Disagree more than about one time in ten, and the judge has drifted, every score since then is unreliable, and the regression suite you have been trusting is an expensive random number generator with excellent manners.

Almost every product team running evals is doing neither. They are doing monitoring and calling it the whole system.

A golden set is not a test. It is a signed log of every judgment your product team ever made about what good means, and its whole value is that you can subpoena it when a vendor swaps the model underneath you at two in the morning on a release nobody consulted you about.

A benchmark is a character witness.

A scenario is an alibi.

Only one of them was actually there.

An eval is not a grade you give a model.
It is a promise you make to the customer,
written down before you were tired.

Try This Over the Weekend

The NASA & HACCP stories handed you two principles, and both are the reason you are about to open a notebook.

Yes kids, this is where it gets a little bit harder, but it’s worth it.

Validation asks whether your rubric can catch the failure you actually fear. Verification asks whether your judge still agrees with a human. You faked the first by hand at the kitchen table, twenty rows on a Saturday. Neither gets honest until something can read the whole batch and re-grade last quarter on demand. That is the only reason to reach for code. Not because notebooks are holy. Because a for-loop reads two hundred rows in the time you read four, and you cannot calibrate a judge you can only run once.

A notebook is just a document where plain writing and small blocks of runnable code share one file. Google Colab runs one in your browser with nothing to install. Jupyter runs the same thing on your laptop if you would rather keep your data on your own disk. Pick the door that scares you less.

You will need an AI API key, which is not a ChatGPT or Claude subscription. Those are the chat apps. An API key is a separate credential that lets code talk to the model directly and bills by usage. You get one from whichever model your product runs on, most likely OpenAI or Anthropic. It arrives looking like a cat walked across a keyboard, and it goes in your environment, never into a cell you might screenshot or push to GitHub at eleven at night. Where exactly depends on your machine, and that is the one part worth not muscling through alone. Paste this into a fresh chat and let it walk you one step at a time:

You are my setup guide. I am a product manager, not a developer, setting up a notebook to run AI evals. Walk me through it ONE step at a time. After each step, wait for me to say “done” or paste what I see before giving the next.First ask, one at a time:
  1. Google Colab in my browser, or Jupyter on my laptop?
  2. If laptop: Mac or Windows? Then guide me, adapted to my answers, through:
  - Which AI API provider my product uses and where to create a key.
  - Storing the key safely:
      * Colab: the Secrets panel (key icon, left sidebar).
      * Mac: an export line in ~/.zshrc, then source ~/.zshrc.
      * Windows: setx in PowerShell, then reopen the terminal.
  - If Colab: connecting the notebook to Google Drive so my work survives
    the tab closing.
  - A one-line test to confirm the key works before I run anything real.Plain language, no jargon without a one-line definition. If I paste an error, diagnose it and give the fix. If I say “skip,” move on. Keep each step under
two minutes.

Then watch the copy-paste disappear. Remember pasting each question, waiting, pasting the answer back, wanting to die? That was you being a for-loop. The notebook does all of them, across every model you name, while you refill your coffee. That is validation at scale: every answer to every question, on the record, before anyone walks into a room to be impressed.

The scary-looking part, the automatic scoring, is nothing but the sentence you already said in your head. When you decided a row passed, you ran a rule. “I marked yes when the answer showed a formula or a dollar figure.” In the notebook that sentence is four lines:

def has_math(text):
    # I marked yes when the answer showed a formula or a dollar figure.
    return bool(re.search(r”[×x*=]|ARPU|USD”, text))

The comment is your judgment in English. The line under it is the same judgment in a language the machine reads. You are not learning to code. You are watching your own Tuesday get spelled in regex.

Then the notebook hands you the part it cannot do. It opens a little cockpit, one trace at a time. The prompt on top, exactly as asked. The raw answer underneath, nothing cleaned up. Checkboxes for the flags it is unsure about, a verdict dropdown, a box asking why it is weak and what good would have looked like. Prev. Save. Next.

And down in the corner, the line that changes everything: 1 of 20 (and not 1/33 ass show!-)

Not the take that sang. All twenty. The blinking brother-in-law included. You are not judging the demo’s greatest hit anymore. You are judging the batch, and the counter will not let you pretend the other nineteen do not exist. Every verdict you save is another line in the record you can open six months from now when the model changes underneath you and the scores move for reasons nobody logged.

If you would rather see the cockpit before wiring your own, there is a working version in a Github repo built around this exact TAM-SAM-SOM scenario. Clone it, run it top to bottom, watch the counter climb to twenty, then gut it and put your product in its place:

• github.com/deanpeters/evals-for-product-managers.

Then take the field kit with you.

The Field Kit

Everything above is the artifact. Take it in this order.

1. The generator prompt. Twenty rows, ninety seconds, from a policy you already have. Then one more, added by hand, from the incident nobody wants to talk about. A model will not write that one. It is trying to be helpful.

2. The spreadsheet. GOOD, WEAK, FAIL. One behavior, twenty situations, fifteen minutes. Your first rep. Do it before you read another article about evals, including this one, again.

3. The acceptance-criteria bridge. Write the eval as the probabilistic cousin of Gherkin. Not “the answer should be good.” Instead: under these conditions, this behavior must stay acceptable within these limits.

4. The hazard list. Four bullets naming where the bad thing enters, written before anyone opens a framework tab. If a hazard cannot be said out loud in a meeting, it is not named yet.

5. The limits block. Four conditions replacing one adjective. Paste it into the PRD where “the answer should be accurate” is currently loitering.

6. The eval file. Hazards, control points, limits, decision rule. Versioned, beside the prompt, changed together.

7. The validation check. Your worst real failure, run against your own rubric. If it passes, the rubric is decoration.

8. The verification log. Thirty cases, two blind graders, one judge, one disagreement rate. Run it every time the model version changes underneath you.

Oh, and The repo … in case you missed it the first time … every prompt above, the spreadsheet columns, the scenario files, the notebooks, and the cockpit live at:

• github.com/deanpeters/evals-for-product-managers.

Copy it, run it, then put your product in its place.

If you find yourself adding a fifth scoring dimension before you have written down one number, step back and ask whether the complexity is earning its keep or merely expressing anxiety as taxonomy.

Why Scoring Traces Beats Chasing Benchmarks

Every time a new model drops, the same breathless cycle fires up. Influencers race to post the leaderboard screenshot. LinkedIn fills with takes about which bar got cleared. A Vice President forwards the post to your Slack channel with no comment, which is somehow worse than a comment, and for about forty-eight hours everybody on the product team feels a faint pressure to stop what they are doing and have an opinion.

Do not stop what you are doing.

Unless you are building frontier models or fine-tuning bespoke ones, benchmarks are not your deliverable. They are somebody else’s, and that somebody has a title with “data” or “engineering” or “ML” in it and a very different Wednesday than yours. Let them run the model comparison. Better yet, hope your DevOps team has already automated it as a gate in the pipeline so nobody has to run it by hand at all.

Your job is the traces.

Your job is the twenty rows, the human_verdict column, the one-line reason, the reference response that says what good would have looked like. Your job is the four rules you wrote before you were tired, the hazard you named out loud in a meeting, the limit you pasted into the PRD where “the answer should be accurate” used to loiter unchallenged. Your job is the signed record of what your product team decided good means, kept in a place you can open when the model changes underneath you and the scores move for reasons nobody logged.

A benchmark tells you which model is generally smarter.

A labeled trace tells you whether your product did the right thing, for your user, in this specific situation, against the rules you wrote down.

One of those is a character witness. The other was actually in the room.

I am not against the pageant and I never was. Keep the benchmarks. Let engineering run them. But do not confuse a leaderboard for evidence that your product works, because a model that scores higher on a benchmark can still hallucinate your refund policy, and the leaderboard will not be in the war room when that happens.

This is also why the two vendors I name up top ended up on opposite trees. Datadog builds harnesses to verify agent-written code before it ships, which is engineering’s job and a good one. Pendo went the other way and built agent analytics for Product Managers, which is the labeled trace with a nicer dashboard. One camp proves the code runs. The other proves your product did the right thing for your user, which is the whole point of everything above.

Regardless of the approach, what YOU need are four small habits, a written-down definition of good, and the discipline to be wrong on paper before you are wrong in front of a customer.

The pageant changed. The hazards did not.

Dean Peters is a principal instructor and consultant at Productside, where he teaches outcome-based product management, AI Product Management, discovery, and the AI workflows product teams actually use once the demo is over. He believes AI should assist, accelerate, augment, and amplify the work, never replace the thinking, and that Product Managers are not Jira-slinging ticket monkeys. He gardens, writes parody, and has strong feelings about em dashes.

Yeah, you heard me, Big stinkin’ whoop!

Why? Because you still have to prompt the loop. You still have to prompt the goal. You still have to prompt the batch and the routine. Nobody skipped a step, they just renamed the step and put a slash in front of it.

And here’s the part the fad conveniently leaves off the slide: the second you’re prompting a loop, you’re one bad instruction away from a runaway loop that won’t stop, or a batch that quietly burns your context window recomputing the same thing forty times before it hands you an answer that cost you triple the tokens for zero extra insight.

I still have the book that taught me why that happens. Leen Ammeraal’s Programs and Data Structures in C, Wiley, 1987, a full decade before he ever put C++ in a title. I was studying software engineering and C at Columbia in the late 80s when it crossed my desk, and it’s one of the few from that era that never made it to a donation box. Four rules from that book still keep me out of trouble today the same way they kept me out of trouble as a C programmer back then:

1. Calculate once, iterate often. Don’t recompute the same expensive judgment call on every pass through a loop.

2. Order your checks by cost, not by alphabet. Cheap checks first, expensive reasoning only when the cheap check didn’t already clear it.

3. Index before you search. Build the lookup once, don’t rescan the whole list every time you need one thing from it.

4. Know your critical path before you loop. Some items block others. Sequence matters more than the loop itself.

One more thing before we get into it, because this is written for Product Managers, not developers. Nothing below asks you to write a function, a macro, or recursive anything. If you can write “for each story in this list, check it and act“ as a sentence, you already have everything you need. In other words, take from this post what helps you get real product management shit done. File away the rest to impress your peeps at an upcoming ProductTank or ProductCamp Meetup which will invariably cover loops, goals, batches, and routines with an influencer energy that’ll make you wanna run down the halls screaming, “I’m noo-noo banannas,

Start With What Already Works

This works today, exactly as written, no notation required:

/goal Use Richard Lawrence's story splitting rubric to break this epic into an array of right-sized user stories.

/loop Go through the story array. Split anything that still fails the rubric. Repeat until nothing splits.

/loop Go through the settled story array and render each story in canonical user story format.

That’s the Humanizing Work story-splitting rubric, Richard Lawrence’s original, called through a plain /goal and two plain /loop commands. It’ll run. It’ll probably even produce a decent backlog. I’m not telling you to abandon this.

I’m telling you what you can’t see when you run it this way. You can’t see how many passes it actually took. You can’t see whether it checked the cheap conditions before the expensive ones, or burned tokens doing it backwards. You can’t see whether it rescanned the whole array every time it needed one service’s worth of stories. You can’t see whether it sequenced the output by anything other than the order the stories happened to fall out in.

It’s a black box that usually works, and “usually works” is fine until story seventeen comes out wrong and you have no way to point at what broke.

First, Know How These Things Fail

Goals, loops, batches, and routines are not four names for the same clever trick. Each controls a different part of the work, which means each has its own special way of wandering into traffic.

• A /goal defines where the work is supposed to go. Its failure mode is ambiguity. If the goal does not explain what good looks like, what evidence matters, or when the work is done, the model will keep moving toward something that merely sounds successful. Usually in bullet points.

• A /loop defines what repeats. Its failure mode is motion without progress. Without a ceiling, a stopping condition, or some way to detect that nothing useful is changing, the system can keep polishing the same artifact until the tokens are gone and every sentence sounds like it was raised by a management consultant.

• A /batch defines the scope of repeated work. Its failure mode is scale without visibility. One weak instruction no longer damages one item. It marches through the whole folder, touching everything with the confidence of a Seagull Manager who just discovered automation.

• A /routine defines what becomes reusable. Its failure mode is drift. Somebody changes the instructions, the source material, the rubric, or the model. Three weeks later the output behaves differently, and nobody knows whether the routine improved or merely mutated in captivity.

Four fashionable primitives. Four different risks.

That distinction matters because you cannot govern all four by sprinkling the same generic instruction over them and calling the result safe. A goal needs a destination. A loop needs a stopping condition. A batch needs boundaries. A routine needs a receipt.

A loop without a ceiling is token hemorrhage. A routine without a receipt is folklore.

Play by the Old Rules Before Adding New Syntax

The temptation is to leap from that invisible machinery straight into code-shaped notation.

Resist it.

Most Product Managers do not need Jinja2 as their first defense against a badly behaved loop. They need to apply Ammeraal’s four rules using the language of work they already understand: shaping problems, sequencing decisions, evaluating evidence, and keeping one shaky assumption from breeding an entire litter of downstream artifacts.

1. Calculate Once, Iterate Often

Some context changes as the work progresses. Much of it does not.

The splitting rubric does not need to be rediscovered on every pass. Neither do the epic hypothesis, target persona, desired outcome, constraints, or agreed definition of a right-sized story. Compact those stable inputs into a working brief once, then let each pass focus only on the stories that still need attention.

For backlog work, that stable brief might contain:

• The epic hypothesis

• The target persona and job-to-be-done

• The story-splitting rubric

• The desired customer and business outcomes

• Known constraints and dependencies

• Decisions already made and approved

That becomes the base camp. Each new pass starts there instead of launching another expedition from the airport.

Otherwise, you are paying the system to reread the same epic, reinterpret the same rubric, rediscover the same persona, and produce yet another slightly rearranged summary of things it already knew.

2. Order Checks by Cost

Not every question deserves the full intellectual orchestra.

Before asking the model to perform a nuanced evaluation against a sophisticated splitting rubric, check whether the story contains one recognizable persona, one coherent job, and something resembling an outcome. Before debating whether the story can be split by workflow step or business-rule variation, make sure it is not already three unrelated features hiding inside a trench coat.

The sequence should move from obvious and cheap toward subtle and expensive:

1. Check that the required elements exist.

2. Check that the elements do not contradict one another.

3. Check that the story is not obviously sprawling across multiple jobs or workflows.

4. Only then apply the full splitting rubric and deeper reasoning.

In prompt form, that can be this simple:

First, check whether each story contains one persona, one job, and one outcome.

Only if it passes those checks, evaluate it against the full story-splitting rubric.

Do not send a sommelier to inspect an empty bottle.

3. Index Before You Search

Large epics, long documents, and folders full of source material invite a particularly wasteful kind of prompting: asking the system to rummage through the entire pile every time you need one thing.

Before splitting, drafting, or revising, have the model map the territory. Catalogue the epics, identify the stories, note the workflows, mark the dependencies, record the unresolved questions, and connect each piece of evidence to the claim it supports.

For example:

Before processing the backlog, create an index containing:

1. Each epic and its intended outcome
2. The stories currently associated with each epic
3. Known personas, workflows, and services
4. Dependencies between stories
5. Open questions and missing evidence

Use this index throughout the rest of the workflow.

Do not rescan all source material unless I ask you to refresh it.

Now the model has somewhere to look before it goes wandering through the entire corpus again.

Without the index, every pass becomes another expedition into the same jungle with a fresh hat, a new token budget, and no institutional memory of the trail it cut yesterday.

4. Know the Critical Path Before You Loop

Sequence matters more than repetition.

Do not render beautifully formatted stories before deciding whether the epic itself is coherent. Do not polish acceptance criteria while the underlying job-to-be-done is still being argued over in another room. Do not split a story by workflow step before understanding whether those steps genuinely depend on one another.

For backlog work, the critical path might look like:

1. Validate the epic hypothesis and intended outcome.

2. Confirm the target persona and job-to-be-done.

3. Identify major workflows, rules, and dependencies.

4. Generate the initial story set.

5. Apply the splitting rubric.

6. Review stories for outcome alignment and independence.

7. Render the approved stories in the desired format.

The exact sequence will vary. The principle will not.

Do not loop on step six while step two is still under negotiation. Otherwise every elegant downstream artifact becomes a hallucination wrapped in a bullet point stuffed inside a strategy recommendation.

The tools changed.

The physics did not.

Use Loop Lingo Before Loop Logic

Once the four rules are understood, the next level of sophistication is still not Jinja2.

It is teaching the model how to take turns.

Product Managers already understand this motion. We do not walk into a discovery session and demand that the room leap from an ambiguous problem to a complete product specification in one heroic act of alignment. We break the work apart. We narrow the question. We examine one piece, make a decision, and use that decision to inform what happens next.

Your prompt should do the same.

Instead of asking:

Split this epic into stories.

Review all the stories.

Improve anything that fails the rubric.

Repeat until the backlog is complete.

Try:

Work in a multi-turn fashion.

First, identify the major workflows, business rules, and dependencies inside this epic.

Then process one workflow at a time.

For each workflow:

1. Generate an initial set of stories.
2. Apply the story-splitting rubric.
3. Identify any stories that remain too large, dependent, or ambiguous.
4. Return the proposed stories for my review.
5. Ask whether I want to modify them or continue.

Do not move to the next workflow until I approve the current story set.

That is loop lingo.

It is not programming. It is a plain-English operating contract between you and the model. It tells the system how to decompose the work, where human judgment belongs, and when it has permission to continue.

And the same discipline applies beyond backlog work. PRDs are simply where one-shot prompting goes to become a larger, more expensive crime scene.

Instead of asking:

Write the complete PRD.

Review every section.

Improve anything weak.

Repeat until the PRD is complete and excellent.

Try:

Work in a multi-turn fashion.

First, identify and list the sections required for this PRD.

Then work through the sections one at a time.

For each section:

1. Identify the approved context and evidence relevant to that section.
2. Draft only that section.
3. Surface any assumptions, contradictions, or missing evidence.
4. Ask me whether I want to modify the section or continue.

Do not move to the next section until I approve the current one.

The artifact changed.

The motion did not.

Whether you are splitting an epic, drafting a PRD, synthesizing research, mapping assumptions, or comparing competitors, you are asking the system to do four things:

1. Break the work into meaningful units.

2. Process one unit at a time.

3. Return control to the Product Manager at each decision point.

4. Continue only after the current work is approved.

The loop does not replace the prompt.

The prompt teaches the loop how to behave.

Compact the Context as You Go

Breaking the work into turns solves half the problem. Each turn also needs a smaller context and a more focused ask.

Context is expensive, both in tokens and attention. Every time you dump the whole backlog, six epics, eight interview transcripts, three personas, two strategy decks, a competitive analysis, and somebody’s seventeen-page Slack argument into the model, you increase the chance that it spends its energy admiring irrelevant furniture.

More context is not always more rigor.

Sometimes it is merely a larger haystack with a more expensive needle.

A solid multi-turn workflow follows a simple rhythm:

1. Map the complete work. Identify the workflows, sections, categories, chapters, epics, or decisions.

2. Select the next unit. Focus on one bounded section, workflow, or question.

3. Pull forward the minimum useful context. Include the goal, approved decisions, relevant evidence, constraints, and dependencies.

4. Make one focused request. Draft, evaluate, split, compare, or test one thing.

5. Ask the Product Manager to modify or continue. Keep human judgment inside the workflow.

6. Compact the approved result. Carry forward the decision and essential context without dragging the entire conversation behind it like a steamer trunk.

7. Repeat with the next unit.

Each request becomes smaller and easier for the model to focus on. Each output becomes easier for the Product Manager to judge. Each weak assumption has fewer places to hide.

And when something goes sideways, you rerun one story set, workflow, or PRD section rather than feeding the entire artifact back into the machine and politely requesting another full autopsy.

One-shot prompting produces documents. Multi-turn prompting preserves decision points.

That is the Product Manager difference.

Add Boundaries Before You Add Braces

For many Product Managers, loop lingo and a little plain-language discipline will be enough. You can make the important controls visible without adding a single curly brace.

For example:

For the goal:

- State the intended outcome.
- Define the evidence or conditions that indicate success.
- Stop when those conditions are satisfied or when Product Manager judgment is required.

For the loop:

- Repeat no more than three times.
- Stop earlier if no material changes remain.
- After each pass, report what changed and what still requires judgment.
- If the same issue survives two passes, stop and ask me how to proceed.

For the batch:

- Process no more than ten epics in one run.
- Handle one epic at a time.
- Report the result and unresolved issues for each epic.
- If one epic fails, stop there rather than quietly contaminating the rest of the batch.

For the routine:

- Identify the routine name and version in every output.
- Record the source files and rubric used.
- List assumptions, skipped items, and failures.

Nothing here requires programming.

It requires specificity.

The model understands the intended flow. The Product Manager knows where they can intervene. And everybody has something slightly more useful than, “Well, it usually works.”

Commit the Ultimate Heresy

Sometimes plain English is not enough.

Maybe the prompt has graduated from something you use occasionally into a /routine other people depend on. Maybe a /batch is about to touch forty epics while you are elsewhere drinking coffee and making optimistic assumptions about how well things are going. Maybe your organization demands governance, guidelines, guardrails, repeatability, auditability, and enough receipts to satisfy a risk committee trapped in a windowless room.

That is when you might season the markdown with Just Enough Jinja2.

JEJ

Not a second career. Not macros, functions, recursion, inheritance, or whatever other incantations cause normal Product Managers to back slowly toward the exit.

Just enough visible logic to clarify what the multi-step prompt is supposed to do.

A bounded loop might look like:

{% for pass_number in range(1, 4) %}
Review pass {{ pass_number }}.

Stop if no material changes remain.

If the same issue survives two passes, ask the Product Manager how to proceed.
{% endfor %}

A batch boundary might look like:

{% for epic in epics[:10] %}
Process {{ epic }}.

Return its stories for review before moving to the next epic.
{% endfor %}

And a routine receipt might look like:

{% set routine_version = "backlog-split-v1.2" %}

Generated by {{ routine_version }}.

That is enough to make the intended structure visible without turning the prompt into a small software project wearing markdown pants.

The markdown still explains the purpose, context, judgment, and desired outcome. Jinja2 merely exposes the places where the system repeats, stops, limits scope, or identifies itself.

Markdown remains the meal.

Jinja2 is the seasoning.

Use a light hand.

The moment the prompt requires a debugger, a code review, and a pale engineering lead whispering, “Who did this?” you have over-salted it.

Yes, This Is More Work

Let us not pretend this sophistication comes free.

Breaking the work into sections takes time. Defining the sequence takes time. Compacting the context takes time. Adding modify-or-continue checkpoints, loop boundaries, batch caps, and routine versions takes time. It is more prescriptive, less spontaneous, and occasionally a colossal pain in the ass.

For a casual one-off prompt, that ceremony may be ridiculous. You do not need a governed, versioned, multi-turn routine to rewrite a meeting invitation, suggest five headlines, or make your email sound slightly less like it was dictated during a hostage negotiation.

But once the prompt becomes infrastructure, the economics change.

When your elegant one-line /routine works, invisible logic feels magical. When it fails, invisible logic becomes a locked room containing your tokens, your afternoon, and seventeen user stories that all somehow forgot the user.

The extra structure gives you something to inspect:

• Which workflow or section was active?

• What context did it receive?

• Which pass was running?

• What condition allowed it to continue?

• Which item in the batch failed?

• Which routine version produced the output?

• Where can the workflow resume without rerunning the entire parade?

Without that logic, your diagnosis is: “Something somewhere in the batch went wrong.”

Terrific.

With the logic, you can identify the failed step, inspect the instruction, adjust the relevant control, and continue from a known point. You spend more time designing the route, but far less time wandering through the wreckage carrying a flashlight and blaming the model.

That is the bargain.

Why Scripted Beats Silent

/loop, /goal, /batch, /routine, keep using every one of them exactly the way you already type them. I’m not against the primitives and I never was. I’m against running them unseasoned and calling the result governed, when all you actually have is a black box that hasn’t failed yet. A /loop is not a strategy and a /goal is not an outcome, but a /goal, /loop, /batch, and /routine seasoned with four rules a Dutch professor put in a textbook before most of these platforms’ founders were out of grade school, that’s an auditable set. You don’t need to write code to get there. You need four small habits, a light hand with the salt, and the discipline to season the commands you’re already writing.

The worked examples in this post, including the loops, goals, batches, routines, and supporting product-management prompts, are now live in the loops directory of my product-manager-prompts library.

So don’t wait for the rewrite.

It landed.

And yes, this is exactly the kind of AI and Product Management work I teach and coach at Productside. For those who can’t wait, I’ve added a loops subdirectory to my nearly-world famous “Product Manager’s Prompts” github repo.

Break, not because the tools are bad. Some of them are astonishing. Not because Product Managers are lazy. Most are already duct-taping together strategy, discovery, stakeholder management, evidence gathering, market sensing, and whatever fresh circus peanut landed in Slack while they were trying to eat lunch.

It breaks because product work is context work.

And most product teams still treat context like meeting exhaust.

Strategy in decks. Decisions in Slack. Metrics in dashboards. Customer pain in research notes. Competitive context in somebody’s browser tabs. Roadmap rationale in a quarterly planning artifact with the half-life of gas station sushi. The reason we are not doing the thing everyone keeps asking about? Living in the hippocampus of whoever was there two reorganizations ago and has since moved to a company with better snacks.

Now drop five AI tools into that mess and ask the team to move faster.

Faster into what, exactly?

The scene

You have seen this meeting.

Maybe it was Tuesday. Maybe Q3 planning. Maybe one of those meetings with a title so vague it could legally qualify as mist.

Someone asks the question.

“Should we prioritize enterprise SSO, the mobile redesign, or the pricing experiment?”

Nobody says anything at first. Which is never a good sign. That silence has weight. The kind that arrives right before a product team discovers it has been carrying three different strategies in one trench coat.

Then one Product Manager says:

“I asked ChatGPT, and it said SSO is the highest leverage because it unlocks enterprise conversion.”

Another says:

“Interesting, Claude suggested the mobile redesign because retention risk is higher than acquisition risk.”

A third says:

“Gemini said pricing because we have margin pressure and packaging confusion.”

All three answers sound reasonable.

All three are written beautifully.

All three have that confident little shine AI puts on things when it has been given just enough context to be dangerous and not enough context to be useful.

Nobody is exactly wrong.

Nobody is working from the same pantry.

So now the team does what product teams do when they are tired, underfed, and haunted by OKRs: they debate the answer instead of the context that produced it.

This is how AI turns a normal product disagreement into a symposium of Confident Nonsense.

Not because AI is evil.

Because everyone fed the machine a different lunch.

The mess was already there

Private AI sessions did not create the problem.

They just made it look ridiculous enough to notice.

Before AI, product context was already sprayed across the organization like someone loaded a leaf blower with strategic intent and aimed it at a SharePoint migration. For example:

• Tools: Decks, Docs, Slack, Jira, Confluence, Miro, Figma, Gong, Salesforce, Zendesk, Amplitude, Tableau, Productboard, Aha!

• Types: Roadmap spreadsheets, research summaries, sales anecdotes, support tickets, win-loss notes, executive offsites, customer advisory boards, random voice memos from a conference hallway.

• That One: spreadsheet from 2022 everyone still uses because it has the “real” segment definitions, except no one remembers who made it or whether Legal blessed the assumptions.

We called these collaborations. How adorable.

The team survived because humans are weirdly good at patching missing context in real time. We ask around. We remember. We triangulate. We whisper, “Is this still true?” to the person who looks least dead inside. We search Slack archaeology. We reconstruct decisions from calendar invites and vibes.

And it was bad, but at least it was human bad.

Now it is machine-assisted bad.

AI does not patiently reconstruct your organizational memory from vibes and forehead wrinkles. It consumes what it can reach, ignores what it cannot see, guesses around what is missing, and writes the result in prose so clean it makes the error feel house-trained.

Before, scattered context created slow confusion.

Now it creates polished confusion at scale.

Our tools were never built for this

This is where someone usually raises a hand and says:

“But we already have a data lake.”

Of course we do.

We have:

• Data lakes, Data warehouses, Data marts, Knowledge bases, Wikis, Document repositories, Ticketing systems

• BI platforms, Search tools, Collaboration suites, Governance layers, Taxonomies, Ontologies, Metadata catalogs, Graphs, Tags, Labels, Permissions, Retention policies

• Dashboards that no one trusts and dashboards that everyone trusts too much

We have enterprise systems the way some families have storage units.

Full. Expensive. Technically organized. Emotionally unresolved.

And to be fair, many of those systems solve real problems. They help store information. Retrieve information. Govern information. Report on information. Move work from one state to another with all the grace of a DMV form wearing a lanyard.

Useful. Necessary. Not enough.

Why?

Because most of those systems were not built for generative AI.

They were not built for:

• Chatbots

• Agents

• AI coding harnesses

• Shared project memory

• Reusable prompts

• Agent skills

• Workflow automation

• The strange new reality where individuals, teams, groups, and machines all need to reason from overlapping but not identical context

They were built to answer questions like:

“Where is the data?”

“Who can access the document?”

“What is the status of the ticket?”

“Which dashboard shows conversion?”

Put another way, they were not built to answer the question generative AI keeps throwing onto the table like a dead fish:

“What should the machine treat as true right now, for this group, on this initiative, with this owner, under these constraints?”

That is a different animal.

That is not just storage.

That is something we now call context engineering.

And yes, I know some Product Managers just read the word engineering and started looking for the nearest exit. Stay with me. Nobody is asking you to become a discount platform architect with a YAML tattoo.

At least not yet.

Context engineering, for Product Managers, is the practical work of making the right information available, current, trusted, labeled, reusable, and understandable enough that humans and AI systems can reason from the same starting point.

Not perfect, but usable.

There is a difference.

A banquet is not required. We are trying to label the pantry.

Better prompts don’t touch this

Naturally, the first instinct is to blame the prompt ... because prompts at least feel fixable.

So the team builds a prompt library. Someone creates a “Prompting Best Practices” page. A consultant shows up with a framework, a laminated card, and the haunted confidence of a person who has never had to defend a roadmap to Sales.

• Prompt libraries help.

• Shared session starters help.

• Reusable instructions help.

• Skills help.

• Connectors help.

• Agents help.

• Plugins help.

• AI coding harnesses help.

All of that is movement in the right direction.

But better prompts aimed at broken context just produce better-written disagreement.

And teaching everyone to follow the same recipe does not help if everyone is shopping from a different pantry.

One person has fresh customer evidence. Another has an old deck. Another has the CFO’s margin panic. Another has a Slack thread from the VP of Sales. Another has a dashboard where “active user” means “opened the product once and sneezed near a button.”

Same prompt + Different ingredients == Different meal.

Then we act surprised when dinner tastes like a hallucination wrapped in a strategy memo stuffed inside a quarterly planning ritual.

The prompt was never the whole problem.

The prompt was the ladle.

The soup was already weird.

The platforms are catching up

This is the part that makes the timing interesting.

Google just introduced the Open Knowledge Format, or OKF. It is a lightweight, open specification for representing metadata, context, and curated knowledge in a way that is readable by humans and usable by agents.

That sounds technical because Google is Google, and if they described a sandwich, someone would eventually mention interoperability.

But under the hood, the signal is simple:

• The model is not enough.

• The agent is not enough.

• The chat window is not enough.

AI systems need context they can find, trust, traverse, and reuse.

Google is not the only one circling this problem. OpenAI is moving deeper into workspace agents, shared agents, connected apps, Slack execution, permissions, repeatable workflows, and team-level patterns. Anthropic has Projects, project knowledge, shared project permissions, memory, Claude Code, Claude Enterprise, and organizational controls.

Different vendors. Different packaging. Same gravity.

The market is moving from:

One person.
One chat.
One output.

Toward:

Shared context.
Shared memory.
Shared agents.
Shared workflows.
Shared governance.

Good.

Late.

Welcome to the party, peeps. We have been waiting by the burnt appetizer tray.

To be clear, much of this vendor movement is still aimed first at engineering teams, data teams, IT teams, and enterprise operations. That makes sense. Those teams have clearer system boundaries, better artifact discipline, and fewer stakeholders wandering in from the tall grass carrying “just one quick request.”

But product teams have the same disease.

Actually worse.

Because product work is not just data. It is judgment sitting on top of data, evidence, constraints, customer understanding, market movement, business goals, technical reality, organizational politics, and the occasional HiPPO wandering through the brush with a PowerPoint clicker clenched between its teeth.

A shared AI workspace helps ... shared agent skills help even more ... shared projects definitely help.

But none of those solve the deeper product problem by themselves.

Because shared memory is not shared meaning.

Shared memory is not shared meaning

This is the turn most tool conversations miss.

A bigger shared AI workspace can still be a bigger junk drawer.

Now everyone’s AI can reach the same mess:

• Six strategy decks

• Four definitions of activation

• Three pricing narratives

• Two research summaries that contradict each other

• One ancient roadmap decision with no rationale attached

• Slack threads pretending to be institutional memory

• Customer quotes with no segment context

• Sales anecdotes wearing a fake mustache as evidence

• Competitive analysis from before your competitor bought the company that bought the company that copied your onboarding flow

Now your AI can find it all.

Congratulations.

Your team can retrieve confusion faster.

This is where people confuse access with alignment.

Access means the system can reach the thing.

Alignment means the team knows what the thing means, whether it is still true, who owns it, when it expires, and what should happen when it conflicts with another thing.

Those are not the same.

A refrigerator full of unlabeled leftovers is accessible.

That does not make it dinner.

The pantry needs levels

Product teams do not need one giant knowledge dump.

They need an informational pantry.

Not a data lake ... Not a document landfill ... Not a Confluence space that looks organized until you open the page tree and realize the page tree is where hope goes to be taxidermied.

A pantry.

A place where the team knows what ingredients exist, where they live, what they mean, who put them there, when they expire, which recipes they support, and which combinations should not be mixed unless you enjoy strategic food poisoning.

And the pantry needs levels.

Because not all context belongs in the same place.

Some context belongs to the world … Some belongs to the group … Some belongs to the project. … Some belongs to the owner.

It always gets back to world, group, owner, doesn’t it?

1. World-level context is the big stuff. Company strategy. Enterprise glossary. Brand principles. Regulatory constraints. Approved data sources. Security standards. Operating model. Commercial guardrails. The things that should not change because one team had a spicy offsite and found a marker.

2. Group-level context is the product area stuff. Product vision. Target segments. Personas. Jobs to Be Done. Metric taxonomy. Product principles. Competitive context. Commercial model. Shared constraints. The stuff a product area needs so its people are not reinventing reality every Tuesday.

3. Project-level context is the working shelf. Problem framing. Desired outcomes. Evidence collected. Decisions made. Assumptions. Risks. Tradeoffs. Open questions. Experiment plans. Current status. Go/no-go rationale. The stuff that explains why this initiative exists and what we think we are learning.

4. Owner-level context is the personal mess. Scratch notes. Draft thinking. Private prompts. Half-formed ideas. Temporary explorations. The intellectual compost pile.

And let us be adults about this: not every private thought belongs in the shared pantry.

Some things need to ripen before the team eats them.

But not every strategic ingredient belongs in someone’s private junk drawer either.

If the activation metric definition lives only in Taylor’s favorite chatbot thread, the team does not have a metric definition.

It has a hostage situation.

OKF is useful because it gives shape to the pantry

This is why Google’s OKF is interesting.

Not because Product Managers need to run off and worship at the altar of Markdown files with YAML frontmatter.

Please do not become a YAML goblin.

The world has suffered enough.

OKF matters because it points toward a pattern product teams should care about:

• Small chunks of knowledge

• Labels

• Links

• Citations

• Versioning

• Portability

• Human-readable structure

• Agent-readable structure

• A lightweight way to represent context so different tools and agents can consume it without every team inventing its own little context terrarium

That is the useful part.

Not the spec as scripture.

The shape.

Because product teams need to stop thinking only in terms of shared prompts and start thinking in terms of shared context.

A shared prompt says:

“Ask the question this way.”

Shared context says:

“Here is the evidence, definition, constraint, decision, owner, source, freshness, and relationship to the work.”

One helps you ask better.

The other helps you reason better.

That distinction matters.

Because AI is not struggling because it lacks sentence starters. It is struggling because we keep feeding it stale ingredients and asking for a tasting menu.

This is Product Management work

Let me be very clear.

This does not mean Product Managers need to become engineers.

It does not mean Product Managers need to become data architects, platform admins, repo gardeners, ontology clerks, or the poor doomed soul responsible for naming every folder in the enterprise.

Damn it, man, I’m a Product Manager, not a pantry shaman.

But Product Managers do need to care about the quality of the context their teams use to make decisions.

That is not a technical costume.

That is the work.

Product Managers should care about:

• What context matters.

• What evidence counts.

• What decisions need memory.

• What assumptions remain open.

• What metrics mean.

• What sources are trusted.

• What changed.

• What expired.

• What belongs at the world level, group level, project level, or owner level.

• What AI should treat as true.

• What AI should treat as merely available.

• What AI should never be allowed to confuse with evidence just because a very confident executive pasted it into a meeting recap.

This is context engineering for Product Managers.

It is not about making Product Managers more technical.

It is about making product judgment more durable.

Because product judgment is not a vibe. It is not a deck. It is not a roadmap theme in a beautiful gradient. It is a chain of evidence, assumptions, constraints, decisions, and tradeoffs that should survive longer than one meeting and be easier to find than a receipt in a rental car glove box.

When that chain is invisible, AI cannot help the team reason.

It can only help the team perform reasoning.

There is a difference.

One changes the work.

The other makes the theater more convincing.

What to do Monday

Do not:

1. Transform the enterprise.

2. Convene a steering committee.

3. Name a task force.

4. Create a maturity model shaped like a hexagon unless you are under medical supervision.

5. Try to solve this with Claude Cowork.

Instead ...

1. Pick one product area.

2. Pick one initiative.

3. Pick one shelf in your proverbial project pantry.

Start with something small enough that no one can hide behind governance.

Create a first version of the pantry for a real product decision your team is already wrestling with.

Maybe the shelf is metric definitions:

• Three outcome metrics

• Plain language

• Formula

• Source

• Owner

• When last reviewed

• What behavior the metric should and should not incentivize

Maybe the shelf is customer evidence:

• Five evidence points

• Date

• Source

• Segment

• Confidence

• Link

• What it supports

• What it does not prove

Maybe the shelf is decisions:

• The last three meaningful product decisions

• What was decided

• Why

• What alternatives were rejected

• What evidence mattered

• What assumptions remain

• Who owns revisiting it

Maybe the shelf is assumptions.

The things everyone keeps treating as facts because they have been repeated enough times to develop a personality.

Maybe the shelf is glossary terms.

Because nothing says “high-functioning product organization” like discovering that “activation,” “adoption,” “engagement,” “retention,” and “customer value” each mean five different things depending on who had coffee with Finance.

Pick one.

Label it.

Make it findable by humans.

Then make it usable by the AI workflows your team already touches:

• Shared prompts

• Chatbot projects

• Agent skills

• Discovery workflows

• AI coding harnesses

• Roadmap reviews

• Research synthesis

• Story mapping

• Whatever toolchain your team has adopted with the usual combination of enthusiasm, confusion, and procurement trauma

Do not boil the ocean.

Label the first damn shelf.

The punchline

Better prompts help ... shared skills help ... shared projects definitely help.

And Google’s OKF gives us a useful pattern to make this happen.

And while OpenAI and Anthropic are clearly chasing the same enterprise reality from different angles, bear in mind that AI will not save a product team that does not know what it knows.

The future of AI product work will not belong to the team with the cleverest prompt library. It will belong to the team that knows where the brown sugar lives, who bought it, when it expires, and which recipe it was meant for.

Because if the pantry is a mess, AI will not make your product team aligned.

It will just help everyone be cooking up the wrong shit faster, in better prose, together.

Somewhere in my little league years, there was always that kid.

Not the kid who was scared of the ball and praying silently in right field, where coaches often placed small children to contemplate dandelions, mortality, and whether the inning would ever end.

I mean that kid.

The know-it-all.

The dugout lawyer.

The kid who could quote batting averages, explain obscure rules, correct the coach just loudly enough to be heard, and recite baseball card statistics with the solemn authority of a tiny municipal judge. He knew who led the league in RBIs. He knew which major leaguer choked up with two strikes. He knew the infield fly rule, or at least enough of its foggy outer doctrine to make the rest of us wish we had taken up bowling, chess, or light taxidermy.

And one Saturday, he showed up with a birthday present.

A Louisville Slugger.

Not just a bat.

A Louisville-By-God Slugger.

Finely turned ash. Fresh varnish. Smooth barrel. Clean label. The sort of object that did not merely lean against the chain-link fence, but glowed there, radiating status, possibility, and the faint suggestion that Cooperstown had been notified.

The rest of us had whatever our parents could afford, borrow, find in a garage, or remember to throw in the trunk ten minutes before the game. Sometimes that meant a perfectly decent bat with someone else’s name written on masking tape near the knob. Sometimes it meant a suspicious off-brand club from the bargain aisle, technically shaped like sporting equipment but spiritually closer to a table leg with seasonal ambition.

But his bat was the real thing.

And he made sure we knew it.

He carried it like a relic. He leaned it against the dugout fence with ceremony. He picked it up with ceremony. He took practice swings with the grave self-regard of a boy auditioning for a Ken Burns documentary that did not yet exist. By the time he stepped into the box, every kid within earshot had received the message: greatness had arrived, varnished, branded, birthday-funded, and insufferable.

Then he struck out.

Not heroically.

Not after fouling off six pitches and battling like a tiny gladiator under a July sun.

Three pitches.

Three strikes.

He sulked back to the dugout glaring at that beautiful bat like it had betrayed the family.

Second at-bat, same opera, different inning. Third at-bat, the count went bad so quickly the dust barely had time to settle around his cleats before he was trudging back again, wounded and furious, staring at that finely turned fraxinus as if it had opened a trapdoor under the strike zone and pushed him in.

I remember the look more than the strikeouts.

That wounded accusation.

That private prosecution.

That small-boy certainty that the equipment had failed to uphold its end of the bargain. As if birthday presents were supposed to arrive bundled with hip rotation, pitch recognition, hand-eye coordination, and the good sense not to swing at something bouncing toward the next county.

From the bench came the curmudgeon wisdom of every coach, father, uncle, and sunburned baseball philosopher of that era:

“It’s not the bat, dummy. It’s your fundamentals.”

Only they said it with more color.

A lot more color.

Prompt Proficiency: Learned the Tricks

To be clear, I was not the best athlete on the field.

Not close.

I was not the kid coaches whispered about while pretending not to whisper. I was not the natural. I was not the one whose throw made fathers stop mid-conversation and say, “Well, would you look at that.” I was usually trying to be useful, which is a different skill and, frankly, a more durable one.

There is a kind of player who gets on the field not because the gods of sport placed a golden hand on his shoulder, but because he can be trusted not to turn ordinary situations into insurance paperwork. That was closer to my lane. I was not there to hit the ball into the next zip code. I was there to get the bat on the ball, move a runner, cover the bag, back up the throw, and make sure the routine play did not become a traveling circus with cleats.

Eventually, that made me useful.

A consistent contact hitter.

A reliable utility infielder.

Supporting cast.

Not the star under the lights, but the guy who helped the star stay under the lights because somebody else remembered where to stand when the ball went somewhere inconvenient.

That may not sound heroic.

Good.

Most useful work doesn’t.

My father coached hard about that sort of thing. Not the cinematic parts. Not the glory parts. The boring parts. Footwork. Stance. Grip. Throwing motion. Keeping your head down. Knowing where the play was before the ball found you. Making the routine play routine.

Over and over.

Then again.

Then again after that, usually with the tone of a man who believed Western civilization might yet be saved if one child learned to move his feet before throwing across the diamond.

At first, fundamentals feel beneath you. Then they feel repetitive. Then they feel boring. Then one day the ball takes a bad hop, the sun gets in your eyes, your glove feels wrong, the runner is moving, everybody is yelling, and your feet are already where they need to be before your brain can convene a committee.

That is when fundamentals stop being lessons.

They become habits. Muscle memory.

Early 2023 was the AI version of that first birthday bat. ChatGPT showed up in public like a Louisville Slugger leaning against the fence. Claude followed. The rest of us gathered around the dugout, poked at the thing, took a few practice swings, and started believing maybe this time the gear really could change the game.

And it did.

A little.

Product Managers learned tricks because tricks were the first available handle. “Act as…” “Think step by step…” “Use this format…” “Make it executive-ready…” “Give me ten ideas…” Some of it worked, and pretending otherwise would be snobbery wearing a cardigan. Prompt Proficiency mattered. We needed to learn how language shaped output, how specificity changed results, how vague prompts produced vague sludge, and how confident prose could walk into a room sounding like a senior consultant while quietly making things up with the moral certainty of a raccoon in a pantry.

That was useful learning.

Necessary learning.

But a lot of Product Managers learned the bat rather than the swing. They learned how to coax output, not how to frame the problem. They learned how to generate user stories, not how to know whether those stories reflected actual end-user goals, constraints, evidence, or pain. They learned how to produce a roadmap-shaped object, not how to decide whether the roadmap had any business existing.

Because a great bat does not fix a bad swing.

It amplifies it.

If your fundamentals are bad, the shiny new equipment just gives your bad habits more exit velocity. You do not merely miss. You miss louder, faster, and with a receipt. The same is true with AI. A good model will not save shallow thinking. It will scale it. It will polish it. It will turn your vague prompt, lazy framing, and half-digested strategy into something that looks crisp enough to fool a room full of exhausted people on their fourth meeting of the day.

The trick was never useless.

It was just not the game.

A million users in five days proves everyone loves a new bat, until they have to swing at a 97mph split-finger slider.

Agentic Literacy: Learned the Patterns

As I got older, the equipment changed.

Aluminum bats started showing up.

Different weight. Different sound. Different sting in the hands. No crack, just that sharp metallic ping that made every father over forty look like civilization had been personally vandalized.

And sure enough, some of the same kids who complained about wooden bats now complained about aluminum. Then the glove. Then the cleats. Then the uniform. Then the field. Then the wet grass. Then the position change. Then the fact that second base “felt weird today,” which remains one of the greatest courtroom defenses ever offered by a child who missed a grounder.

By then I was starting to see the pattern.

Some people were only good when the conditions were just so.

Same bat. Same field. Same position. Same weather. Same rhythm. Same everything. Change one thing and the whole operation collapsed into dust, grievance, and Capri Sun.

They had learned the surface of the game: the gear, the stats, the rules, the rituals, the posture. But they had not learned the game deeply enough to adapt.

That distinction followed me into music, where I competed to sing opera against people who were better musicians, better sight-readers, better pianists, better everything on paper. Some had cleaner training. Some had prettier instruments. Some walked into a room and made the rest of us suddenly aware of our jaw tension.

Again, I was not usually the hero.

Never the lover. Rarely the glowing prince wandering in from stage left with cheekbones, destiny, and a tenor high note sharp enough to cut glass.

I was more often the supporting principal: the comic, the villain, the schemer, the blustery uncle, the guy who entered with timing, turned the scene, kept the show moving, and made the person in the spotlight shine brighter because the machinery around them did not fall apart.

Not because I couldn’t be the bel canto, but because I relished the role of the catalyst.

I learned to win differently.

Breath. Placement. Diction. Support. Phrasing. Preparation. Discipline.

Not magic.

Fundamentals.

By late 2024, AI had its aluminum-bat moment. The tools were not just chatboxes anymore. They had persistence, Projects, Custom GPTs, shared instructions, longer context, reasoning models, and flow tools like n8n and Langflow. The work started to look less like a conversation with a clever autocomplete box and more like a relay race through a warehouse where context had to be handed from station to station without getting dropped, mislabeled, overstuffed, or sent to Legal wearing a fake mustache.

The question was no longer, “Can I get one decent answer?”

That was batting practice.

The better question became, “Can this product team repeat good work?” Has it become part of their mental muscle memory?

That required Agentic Literacy, which sounds fancier than it is. It meant learning the patterns underneath the tools: how context travels, how tasks decompose, how agents move from step to step, how handoffs happen, where evidence enters, where judgment interrupts, and where the machine needs to stop before it turns a helpful draft into a tiny autonomous liability with a login screen.

A trick says, “Here is the magic phrase that worked for me once under perfect conditions.” A pattern says, “Here is the context, the role, the task boundary, the evidence, the handoff, the review point, and the part where a human being still has to decide whether this thing deserves to live.”

That is the difference between the kid who can hit one pitch in a cage and the player who understands the count, the pitcher, the field, the situation, and whether the runner on second has enough speed to matter.

And this is where the amplifier matters.

A high-end mitt does not teach you footwork. It does not teach you where to stand, when to charge, when to eat the ball, or how to make the second throw before the first one has even landed in your glove. But if your fundamentals are sound, a better glove helps you make plays you might not otherwise make.

AI is the same.

If your product practice is a mess, AI will not rescue it. It will make the mess faster, prettier, and easier to distribute. If your product practice is sound, AI can amplify it in ways that feel almost unfair. Not because the tool replaced the work, but because the tool helped carry the weight of the parts that should never have consumed so much of your attention in the first place.

It can assist.

Accelerate.

Augment.

Amplify.

But only if there is something worth amplifying.

Agentic Literacy moved Product Managers from clever individual prompting to patterned product team practice.

Not one prompt.

A repeatable motion.

Not one lucky swing.

A stance, a rhythm, a way of seeing the pitch before flailing at it with a birthday present.

Systems Fluency: Learned the Game

The same lesson followed me into technology, where every few years the industry burst through the door wearing a new costume and announced that everything before lunch had been rendered obsolete. Mainframes, client-server, the web, XML, mobile, cloud, analytics, Agile, search, natural language processing, machine learning, deep learning, neural networks, data platforms, APIs, DevOps, continuous testing, languages, frameworks, databases, stacks, architectures, platforms, and products all marched past like a forty-year parade of expensive disruption with conference lanyards.

Every wave came with its own birthday bat.

Every wave came with people who knew the vocabulary first and the fundamentals never.

Every wave punished the brittle.

Large language models did not invent disruption. They made it inexpensive, ubiquitous, and weirdly fun. That last part matters. AI did not arrive like some grim enterprise platform with a twelve-month implementation plan, a steering committee, and a vendor who says “journey” too much. It arrived like a toy: a box, a prompt, a blinking cursor, a dare.

Ask it anything. Make it write a poem. Summarize a meeting. Draft a user story. Explain Kubernetes to a golden retriever. Build a prototype. Generate code. Rewrite your resume. Produce a strategy doc so plausible it should probably be held overnight for questioning.

It was fun.

That is why it spread.

Now, by mid-2026, the field is bigger again. We are not just drafting. We are building. Claude Code, Codex, Lovable, Base44, agentic workflows, AI-assisted research, AI-assisted prototypes, AI-assisted delivery, AI-assisted documentation, AI-assisted everything, because apparently no noun is safe anymore.

And the workplace around us is not exactly calm. Layoffs, reorgs, budget pressure, AI-first mandates, board anxiety, and executives asking what roles can be “augmented,” which is sometimes a sincere productivity question and sometimes a cost-cutting sentence wearing a nicer shirt.

Whether AI is actually to blame for every layoff does not matter as much as people think. The disruption is real either way. The fear is real. The pressure is real. The need for resilience is real.

And resilience does not come from memorizing the tool of the month.

It comes from Systems Fluency.

For Product Managers, Systems Fluency means understanding the work beneath the work: problem framing, context design, judgment, evidence, workflow design, evaluation, and governance. It means asking what we are solving, for whom, and why it matters before the model starts singing. It means knowing what the AI needs to know, what it should ignore, where that context lives, what source material grounds the answer, how we test the output before it becomes strategy theater, and who owns the blast radius when the clever thing gets confidently wrong.

This is also where the productivity trap shows up wearing a whistle.

If you chase efficiency directly, you will take your eye off the ball. Goodhart’s law warned us about this: when the measure becomes the target, the measure stops being useful. Chase speed, and people will produce faster. Chase output, and people will produce more. Chase cheaper delivery, and people will find ways to make things look delivered.

None of that means you built the right thing.

The better aim is not efficiency first.

The better aim is amplified fundamentals.

Use AI to learn faster, frame better, inspect more carefully, test more cheaply, compare options, surface assumptions, rehearse decisions, expose weak logic, and help the product team return its attention to the work that actually matters. When those fundamentals improve, productivity and efficiency show up as earned side effects. Not as the god being worshiped. Not as the scoreboard being gamed. As residue from better play.

Because building the wrong thing fast and cheap is not strategy.

It is waste with a stopwatch.

These are not tips.

They are not tricks.

They are footwork.

They are breath support.

They are scales.

They are knowing where to throw the ball before it gets hit to you.

The Field Will Not Hold Still

The tools will keep changing.

Of course they will.

The market rewards novelty, the vendors need growth, the investors need a story, and half the internet needs something new to call “the end of product management” before breakfast. Fine. Use the tools. Learn the tools. Play with the tools. Break the tools.

But do not build your professional identity around the bat.

Build it around the fundamentals.

That is what kept me on the field when I was not the best athlete. That is what kept me competitive in music when I was not always the best musician. That is what kept me relevant in technology across forty years of platform shifts, language churn, data explosions, and innovation waves that kept arriving with the calm, measured dignity of a marching band falling down stairs.

And maybe that is why I have spent so much of my career in the supporting cast that makes the star shine. The contact hitter. The utility infielder. The supporting principal. The comic. The villain. The technologist who can move between domains, translate between worlds, anticipate the next play, and help the product team keep continuity because the fundamentals are already in the hands, feet, breath, and bones.

That may not be as glamorous as being the birthday-bat kid.

It is more useful.

Especially now.

Not because AI is hype.

Because it is not.

Not because the tools do not matter.

Because they do.

But because the people who stay useful through disruption are rarely the ones who memorized the newest label first. They are the ones who can make the play when the field changes.

AI will amplify something.

Your habits decide what.

Stop blaming the bat.

Learn the game.

Make the fundamentals habits. Muscle memory.

That is how you stay useful when the next pitch moves.

I’ve spent the last couple years teaching AI product management to hundreds of practitioners and dozens of organizations.

And I keep hearing the same story.

Twice.

Same plot. Different character. Different crisis.

The first version goes like this: “We’ve got AI everywhere. Tools deployed. Licenses purchased. Pilots running. But nothing is actually changing.”

The second version sounds like this: “Our people are trying. Some are even experimenting. But we can’t get AI to compound into anything that actually moves the business.”

Two organizations. Two flavors of stuck. And in almost every case, the reason is the same:

They’re on different journeys. And they don’t know it.

Two Maps. One Territory.

When I look at AI maturity across the organizations I work with at Productside, I see two distinct models emerging — not as competing theories, but as parallel realities that most orgs experience simultaneously, and usually manage separately, to their detriment.

Call them Blue and Green.

Blue is the operating model view. It asks: How is AI changing the way work actually gets done?

Green is the human-centered view. It asks: How are the people doing the work growing into their AI-augmented roles?

Both matter. Neither is optional. And treating one like the other is where most AI strategies quietly fall apart.

The Blue Journey: AI as Operating Model Transformation

The Blue journey is a systems story.

It moves through five recognizable stages:

Individual Productivity → Team Automation → Workflow Orchestration → Agentic Operations → Adaptive Operating Model

Blue leaders ask questions like:

• Where are we still relying on isolated individual heroics?

• Which workflows should be automated, redesigned, or orchestrated?

• What are agents allowed to decide — and when do humans take the wheel?

• How do we connect AI activity to measurable business outcomes?

• Is the system learning? Or just producing more output?

Blue is not satisfied with “people are using tools.”

Blue wants to know if the work itself is changing. Are handoffs faster? Are decisions higher quality? Are teams spending less time on low-value coordination and more time on judgment, strategy, and execution?

Blue is the map for leaders who need to move past scattered productivity wins and ask whether AI is changing how the business operates.

The Green Journey: AI as Human-Centered Capability Growth

The Green journey is a people story.

It also moves through five stages:

Confident Dabbler → Enthusiastic Experimenter → Tool Fluency → Workflow Builder → Commercial Strategist

Green leaders ask different questions:

• Are people confident enough to start?

• Are they experimenting with purpose or just poking around?

• Do they know which tools fit which jobs?

• Can they move from clever one-off prompts to repeatable work patterns?

• Are they connecting AI use to customer value and commercial outcomes?

Green knows something Blue sometimes forgets: an organization does not become AI-mature simply because tools are available, licenses are purchased, or copilots are enabled.

It becomes more mature when people develop the habits and discernment to use AI well in work that matters.

Green is the map for leaders who know that adoption without fluency is fragile.

The Trap: Using the Wrong Map

Here’s where organizations waste enormous time and money.

If the problem is Green, but leadership treats it as Blue: they over-engineer. They build governance structures, tool architectures, agent strategies, and operating principles before people have built basic confidence and fluency.

The result? A beautiful machine nobody runs well.

If the problem is Blue, but leadership treats it as Green: they over-train. They run workshops, share prompts, celebrate experimentation — without changing the workflows, incentives, data access, or measurement systems around the work.

The result? Enthusiastic activity that never compounds.

Both failure modes are common. Neither means the organization is unserious.

It just means they grabbed the wrong map.

Why Both Journeys Are Required

Blue without Green is systems change without human readiness. People route around it, misuse it, underuse it, or comply on the surface while keeping the real work somewhere else.

Green without Blue is human growth without organizational scale. People get better. The system does not. Local improvements appear. Strategic leverage remains out of reach.

The place where these journeys meet is where AI strategy actually becomes durable.

Individual Productivity only compounds when people become Confident Dabblers and Enthusiastic Experimenters.

Team Automation depends on enough Tool Fluency to know which jobs deserve automation and which ones still need human judgment.

Workflow Orchestration requires Workflow Builders who can connect people, tools, data, and decision points into something repeatable.

Agentic Operations require humans with enough judgment to define guardrails, escalation points, and the conditions under which the agent gets to drive.

An Adaptive Operating Model only matters when leaders have become Commercial Strategists — people who can connect AI capability to customer value and business results.

One journey builds the machine. The other teaches people to run it.

A Better First Question

Most AI maturity conversations start with: “What level are we?”

That question is useful. It’s also incomplete.

The better first question is: “Which journey are we actually on?”

Because if leadership is speaking Blue while teams are living Green, the conversation will feel misaligned from the start. One group talks about scale. The other talks about confidence. One talks about agents. The other talks about trust.

Those aren’t competing realities. They’re different layers of the same transformation.

So. Which Color Is Your Organization?

Are you mostly wrestling with Blue questions?

• How do we scale this?

• How do we govern it?

• How do we redesign workflows?

• How do we measure impact?

Or are you mostly wrestling with Green questions?

• How do we help people start?

• How do we build confidence?

• How do we develop judgment?

• How do we connect AI use to meaningful value?

The answer changes your next move.

Treat a Green problem like a Blue problem: you’ll over-engineer before people are ready.

Treat a Blue problem like a Green problem: you’ll keep training people without changing the system they work inside.

AI maturity isn’t a single ladder. It’s a conversation between two kinds of progress.

How the organization changes. How the people grow.

The strongest AI journeys need both colors.

Dean Peters teaches AI product management at Productside. After two decades of hands-on product management, he’s spent the last four years working with PM leaders and practitioners navigating the intersection of AI strategy, organizational design, and the stubborn human realities that live between them.

Have you heard?
Have you seen?

Of coders who vibe with a sparkle and sheen?
Of PMs who prototype shiny and quick,
Then crown every glittering thing as “the trick?”

Come gather close,
roadmap-weary and worn,
For these seven small sins are routinely reborn.

They slither.
They swagger.
They grin as they pass.

They dress bad decisions in confident class.

1. Lust (for the Demo)

You chased the bright show, not the truth down below.

First comes Lust with a wink and a glow, “Build the shiny!” it whispers. “Now go, go, go!”

So you skip past the problem, You skip past the pain, You skip past the question That needed a brain.

You built quite a spectacle. Slick. Polished. Supremo. But what did it teach you? Not much past the demo.

It wowed all the room. It delighted the crowd. But under the sparkle? No learning allowed.

Result: A glitter-bright puppet with no wisdom inside.

A demo that dazzles the room with its glow teaches you nothing of what you don’t know.

2. Gluttony (of Ideas, Not Just Tokens)

You boil every ocean for each bright notion; testing every little one, yet learning about none.

Then Gluttony storms in with tests by the crate, “Why try only one when you could try all eight?”

Five use cases here, Three personas there, Seven notions half-baked Floating loose in the air.

You stir them together, You call it a sprint, You season it lightly With one customer hint.

But a test of all things is a test of no thing. It makes lots of noise. It proves not a thing.

So wider you wandered, And thinner you learned, With a pile full of effort And no insight earned.

Result: A clatter of motion. A famine of knowing.

Test one small assumption. Let evidence flow, the narrow path teaches what noise won’t show.

3. Greed (for Capability Over Outcomes)

More tricks on display make the meaning decay.

Then Greed cried, “Add features! Add more! Add delight! Predictions! Suggestions! Make everything bright!”

So feature by feature, You stacked up your pride, A pocketknife product With too much inside.

It danced and it dazzled, Did flips in the air, But the one thing that mattered Was simply not there.

The user just blinked. The customer frowned. For the thing they had needed Was nowhere around.

Result: A marvelous muddle of motions and chatter.

When everything works yet nothing feels right, you built for the clapping, not users’ delight.

4. Sloth (Disguised as “Let the AI Figure It Out”)

You handed the thinking to something that’s fast, but fast without judgment puts nothing that lasts.

Then Sloth shuffled in with a yawn and a grin, “The model is clever. Just let it begin.”

No framing. No fences. No sense of what’s good. No map through the murk Where your thinking once stood.

Just vibes in the briefing, Just hope in the thread, Just trust that the machine Would think in your stead.

But answers that sound right Can still wander wrong, They hum like a hymn But don’t carry long.

You didn’t move faster. You simply skipped thought, And what came back polished Was mostly for naught.

Result: A handsome confusion in tidy attire.

Fast isn’t thinking, and prompt isn’t thought, if you don’t define good, good won’t be what’s brought.

5. Wrath (Using the Demo to Win, Not Learn)

You raised up the demo to win, not to know.

Then Wrath grabbed your demo and held it up high, And thumped on the table with, “See? I was right!”

No, “What have we learned?” No, “What should we test?” Just applause-seeking theater Dressed up as its best.

The demo stopped probing. It stopped being a clue. It turned to a hammer For pounding things through.

And decisions were made By the loudest hooray, While evidence quietly Wandered away.

Result: A shouting-match victory. A learning defeat.

When winning’s the goal, then learning will hide, and what you prove loudly is what you ship blind.

6. Envy (of the AI-Native Kids)

You copied the shine, not the why or the how.

Then Envy came racing from posts far away, “They shipped it in hours! Why can’t we today?”

So you copied the surface, The motions, the spark, The glittering screenshot, The bright little mark.

But not the condition, Not market, not need, Not customer context, Not problem, not seed.

So there sat your marvel, All shiny and proper, A splendid new answer With no useful shopper.

A trick in a vacuum, A flourish, a spin, A wagon with wheels, But no horse tucked in.

Result: A polished parade float with nowhere to travel.

Don’t copy the magic you happened to see, learn how they learned, then build what should be.

7. Pride (in the Prototype)

One moment of working is not truth to trust, a flicker’s not fire, a spark’s not robust.

And last came Pride in a confident coat, “It works!” Pride declared with a very full throat.

It worked on your laptop, On Tuesday at two, With just the right data And just the right view.

It worked if untouched, If unstressed, if contained, In rooms full of guessing Where nothing was strained.

So naturally, surely, You inked it in pen, And marched it to roadmap Again and again.

But a moment’s not pattern, A pilot’s not proof, And a prototype’s promise Is not quite the roof.

Result: A tiny success blown up bigger than truth.

A prototype asks, “Here’s something to test,” a roadmap is earned when the answers stand blessed.

Closing Shot

So vibe if you must, But vibe with a reason. Not every bright mockup Is ripe for the season.

Use it to question. Use it to see. Use it to learn What is worthy to be.

For done in the right way, With courage and sight, You’ll kill bad ideas Before they can bite.

But done in the wrong way? Well, that is the code That builds you a feature factory Lit like a road.

Vibe to learn, not to earn as you roam, or you’ll ship what looks clever and miss what feels home.

Here’s one guess:

“How screwed am I if I’m a product manager and I can’t build anything yet?”

That’s the question humming underneath half the PM job market right now.

Not the polished LinkedIn version. Not the conference-panel version where everybody smiles like they have already “embraced the future.” The real version.

The Room Gets Weird

The version where a PM walks into an interview with ten years of discovery work, roadmap scars, stakeholder battle damage, and enough prioritization frameworks to wallpaper a medium-sized church. Then somebody across the table asks:

“Are you a product builder?”

And just like that, the room gets weird.
Because that question does not sound like a philosophy question anymore.

It sounds like a mortgage question.
It sounds like a grocery question.
It sounds like one of those questions where, if you hesitate half a beat too long, you can practically hear some other candidate across town cheerfully spinning up a prototype before you’ve finished saying, “well, it depends how we define build.”

That is what a lot of PMs are feeling right now.

Not curiosity. Not mild intrigue. Not “gosh, what a fascinating market development.”
Panic.
Professional panic.

The kind that arrives when you suspect the market quietly changed the exam while you were still studying the old guide.

And naturally, the internet has responded the way it always does: by hurling bad advice in every direction like a T-shirt cannon loaded with nonsense.

• “Just become technical.”

• “Just learn to code.”

• “Just use Cursor.”

• “Just vibe code a whole app.”

• “Just become a full-stack product leader.”

Yeah ... “Just …” The most condescending word in modern career advice. Right up there with “simply” and “obviously.”

Meanwhile, the PM reading this is thinking:

• I have a real job.

• I have meetings.

• I have a backlog.

• I have a family.

And I do not have six free months to become a discount engineer with a prompt addiction and a haunted side project.

Elegant Little Beast

That is why Marc Andreessen’s one-liner is actually useful.

He described an AI agent like this:

LLM + shell + file system + markdown + cron

Elegant little beast.

Not because it is magical. Because it is simple. It takes a big, squishy, overhyped thing and turns it into a parts list you can actually hold in your head.

Start with a language model. Give it a shell so it can do things. Give it a file system so it can store memory and instructions in plain text or markdown. Add a loop and a trigger like cron so it wakes up.

That’s why the line sticks.
It demystifies the machine.

And more importantly, it gives us a clue about what changed.
The big change is not that these systems appear to think.

Plenty of things appear to think. So do golden retrievers when cheese is involved.
The big change is that thinking, memory, and execution have been separated.

The intelligence becomes stateless. The system becomes stateful.

That means the model is no longer the whole show. It is a component in a larger system. Memory lives somewhere. Instructions live somewhere. Actions happen somewhere. The whole thing can be externalized, inspected, moved, reused.

That matters for engineers, obviously.

But it also matters for PMs, because the same simplification trick can help explain the new pressure landing in your lap.

We Stole the Format. Gladly.

Because if Andreessen can use one line to compress what an agent is, we can use one line to compress what vibe prototyping is starting to mean for product people:

LLM + CLI + file system + markdown + UI

Same rhythm. Same cheap little formula. Different destination.

His line ends in cron because he is describing autonomy. A system wakes itself up and goes to work.

Ours ends in UI because PMs are not being asked to build autonomous agents in interviews. They are being asked to make an idea tangible enough that another human can see it, touch it, react to it, and say, “yes, that,” or “nope, not that.”

That difference matters.

A lot.

Because this is where the bad advice goes off the rails.

PMs are hearing “build” and translating it as:
”I guess I need to become an engineer now.”

That’s not quite right.

The market is not suddenly demanding that every PM become the second coming of a senior full-stack developer who also moonlights as an MLOps goblin and sleeps under a standing desk.

What the market is signaling, clumsily and often obnoxiously, is something more specific:

• Can you reduce uncertainty with your own hands?

• Can you take a fuzzy idea and make it visible?

• Can you get past the meeting, past the deck, past the abstract language, and put something in front of someone before the company commits real money and real engineering time?

• Can you narrow the blast radius of bad assumptions?

• Can you learn faster than the old process allows?

That is the pressure hiding inside the phrase “product builder.”

And that is why so many PMs are freaking out.

Because for years, many of them were taught that their value lived one layer up from making. In vision. In strategy. In prioritization. In alignment. In translating. In coordinating. In influencing without authority, which is corporate America’s favorite way of saying, “good luck out there, champ.”

Now suddenly the market is peeking over the fence and saying:

Cool. But can you show me something?

That lands like a brick.

Especially when the loudest people online are either:

• selling a fantasy

• selling a course

• selling a tool

• selling the idea that if you are not already building apps before sunrise, you are basically a decorative plant with a Jira license

Can You Show Me Something?

So let’s clear something up.

As PMs, we vibe code to learn, not to earn.

That sentence matters because half the current confusion comes from acting like every rough prototype is supposed to become a product by lunch.

No.

• You are not shipping production software.

• You are not replacing engineering.

• You are not pretending a rough prototype and a durable product are the same thing.

• You are not slapping together a feral little app and calling it innovation.

You ARE using new tools to learn.

That’s the frame.

You are using an LLM to help with the thinking. A CLI to help with the doing. A file system and markdown to hold context, instructions, and state. A UI to make the behavior visible enough to test.

Not because the prototype is the product.

The prototype is the flashlight.

It helps you see sooner.
It helps you surface the stupid faster.
It helps you shrink the distance between “interesting idea” and “that won’t work.”

And that is what a lot of PMs need to hear right now.

You do not need to become a better faker. You need to become faster at turning fog into something visible.

That’s it.

And once you see it that way, the scary interview question becomes less mystical.

“Are you a product builder?”

Answer:

I’m someone who can take an uncertain idea, identify a behavior worth testing, and make it tangible enough to get a real reaction before we overinvest.

Now we’re talking.

Because that is the move.

Not building the whole thing. Not wiring up every edge case. Not replacing the team. Not disappearing into a warm fuzzy IDE because terminals hurt your feelings.

Just getting one corner of reality around the bend.

One behavior. One interaction. One visible artifact. One honest reaction.

That is the work.

• Not production. Proof.

• Not polish. Signal.

• Not software theater. Sharper sight.

The Only Question Worth Asking

That is what most PMs actually need to learn.

And it leads to the question this whole article has been building toward:

What is the smallest believable version of a behavior I can make tangible and test?

That question is worth more than half the AI advice currently clogging the timeline.

Because it forces discipline.

1. Smallest means stop trying to boil the ocean just because the tools got faster.

2. Believable means it does not have to be perfect, but it does have to feel real enough that someone reacts honestly.

3. Behavior means stop hiding inside nouns. Not “platform.” Not “solution.” Not “capability.” What does the thing actually do in relation to a human?

4. Tangible means no more interpretive PowerPoint. Something has to show up. A screen. A flow. A draft. A mock interaction. A visible artifact.

5. Test means we are learning, not auditioning for sainthood.

That is what a product builder means, or should mean, in this moment.

• Not “PM who cosplays as engineering.”

• Not “person who writes prompts with unusual confidence.”

• Not “whoever made the prettiest toy app over the weekend.”

A product builder is a PM who can collapse the distance between idea and evidence.
A PM who can make one slice of a future behavior real enough to react to.
A PM who does not need to ship the whole thing to learn something useful.

That is a much more humane bar.

Still demanding. But humane.

Not More.

And frankly, it is also more useful than all the current noise telling PMs to either become coders overnight or accept extinction with dignity.

No.

The job is changing. That part is true.

The expectations are getting sharper. Also true.

But the answer is not panic. And it is not pretending. And it is definitely not swallowing every breathless post from some AI hype merchant who discovered a code editor last Tuesday and now speaks in prophecy.

The answer is to get practical.

• Use the tools.

• Learn the workflow.

• Build enough to see.

• Build enough to react.

• Build enough to reduce risk.

Not more.

That is the work.

So yes, steal the formula.

Use it.

LLM + CLI + file system + markdown + UI

And then pair it with the only question that really matters:

What is the smallest believable version of a behavior I can make tangible and test?

Because somewhere out there, a PM is walking into an interview this week already feeling the ground move under their shoes.

They do not need another guru yelling “just build.”
They need a way to understand what building now actually means.
That’s the job now.

Dean Peters is a Principal Consultant and Trainer at Productside, where he teaches outcome-based product management, AI Product Management, discovery, and the AI workflows product teams actually use once the demo is over. He believes AI should assist, accelerate, augment, and amplify the work, never replace the thinking, and that Product Managers are not Jira-slinging ticket monkeys. He gardens, writes parody, and has strong feelings about em dashes.

The room was alive.

Not “alive“ like a standup where someone remembered to bring donuts. Alive like the moment a team finally stops arguing about the map and agrees on where they actually want to go.

The Why had landed. Clean. Shared. Earned.

Someone had written it on the whiteboard in marker thick enough to mean it. People were nodding the way people nod when they recognize a true thing. There was momentum. There was coffee. There was, briefly, permission.

Then the door opened.

Don Octave had the energy of a man who had just landed from a connecting flight and skimmed the deck summary in the Uber. He surveyed the room with the satisfied look of someone about to add value.

“Great,“ he said, setting down his bag. “So. How will we ---“

He didn’t finish.

Nobody could later explain exactly what happened next. Only that it happened fast. As if he were slapped back to his senses, without being slapped. And that the word “will“ hung in the air like the first crack in ice you thought was solid.

“Watch your mouth!“

Commanded Leona Pryce, AI Product Manager extraordinaire, as she then shifted her maternal glare from Don Octave upwards. Not towards the ceiling exactly, but more like at something beyond the drop tiles and the fluorescent hum. Something that required a moment of genuine address.

“Solution, ---“ she commanded as if driving pigs into a lake, “get thee behind me!“

The room held its breath.

Someone capped the whiteboard marker. And they got back to work.

We will come back to Leona. And to Don. And to the two words that almost quietly sabotaged six months of their lives.

But first, a grammar lesson nobody asked for. And everybody needs.

The Crime Scene: Two Words, One Wrong Turn

Two words separated a discovery session from a deployment plan.

Will. And might.

You would be forgiven for thinking this is pedantic. You would be wrong.

“How will we“ is a verdict dressed as a question. It sounds like leadership. It sounds like momentum. It is, in practice, a quiet surrender to a solution that arrived too early and refused to leave.

“How might we“ is something else entirely. A posture. A deliberate refusal to let the solution arrive before the problem has finished speaking. It keeps one foot in the Why and gestures, carefully, toward the What. Without touching it yet.

The difference is not semantic. It is architectural.

“Will“ Is a Closing Argument

When Don Octave said “How will we,“ he wasn’t asking a question. He was opening a negotiation in which the outcome had already been decided. Somewhere between the airport and the conference room, the What had materialized. The AI agent. The copilot. The chatbot. The thing that was going to fix it.

Now all that remained was the how. The execution. The roadmap. The sprint planning.

Discovery, closed. Building, commencing.

The problem space? Escorted out the side door before it could object.

This is solutionism. It doesn’t kick the door in. It slips into the meeting wearing curiosity like a borrowed jacket, orders the same coffee, nods at the Why work, and then quietly takes the wheel.

“Might“ Is a Bridge

“How might we“ was born at Procter & Gamble in the 1970s. Min Basadur brought it there. IDEO sharpened it. Google and Facebook made it viral. Stanford’s d.school baked it into the design thinking canon as the bridge between Define and Ideate.

That lineage matters. Because “How might we“ was never meant to be a planning tool.

It was built to stop exactly what almost happened in that room.

The NN/G puts it plainly: HMW questions exist to frame design challenges and prevent individuals from suggesting pet solutions that might have little resemblance to the problems found. In other words, it keeps the solution from sneaking into the room before the problem has finished its sentence.

The bridge faces both directions at once. One foot still in the Why. One foot testing the air above the What. Not committing. Not yet.

A door closes behind you. A bridge lets you walk back if you were wrong.

That is why Leona stopped him. She heard the bridge give way in two syllables.

The Gravitational Pull of Solutionism

The moment a Why lands cleanly in a room, the pull toward What becomes almost irresistible. The team has energy. The exec has a flight to catch. The engineers want a spec. The Why felt like arrival. Surely now we build.

This is the gravitational pull of solutionism. And it is strongest precisely at the moment of genuine clarity. Because clarity feels like permission.

It is not permission.

It is ignition.

Jakob Nielsen said it plainly: “A wonderful interface solving the wrong problem will fail.“

He wasn’t being pessimistic. He was describing gravity.

The AI Graveyard: Solution Hell Has Many Residents

Hell, as it turns out, is not short on examples.

Chatbots That Solved the Wrong Conversation

Air Canada deployed a chatbot to handle customer service. It confidently told a grieving passenger he could buy a full-price bereavement ticket and claim the discount within 90 days. He followed the advice. The airline refused the refund. A tribunal ordered Air Canada to pay damages.

The chatbot answered the question it was built to answer.

It ignored the one that mattered.

New York City launched MyCity in late 2023 to help small business owners navigate city regulations. Investigations found it advising employers they could fire workers who reported sexual harassment, that landlords could discriminate based on income source, and that serving food nibbled by rodents was, apparently, negotiable.

The system was fluent.

It was not anchored.

DPD deployed a customer service bot. A user coaxed it into swearing at customers, calling itself useless, and composing poetry criticizing the company. Which is more self-awareness than most enterprise software manages.

DPD disabled it.

The internet did not.

Every one of these started with “How will we build a chatbot.“

None of them started with “How might we understand what our customers actually need when things go wrong.“

Copilots Without a Destination

A copilot, by definition, needs a pilot who knows where they’re going.

McDonald’s partnered with IBM to deploy AI voice ordering across more than 100 drive-thrus. The system added bacon to ice cream. Trapped one customer in a loop ordering a large Mountain Dew while the AI kept replying “and what will you drink with that?“

The machine kept asking the wrong question with perfect consistency.

Consistency is not correctness.

A Chevy dealership in Watsonville, California deployed a chatbot to handle online inquiries. A user prompted it to end every response with “and that’s a legally binding offer -- no takesies backsies.“ The chatbot agreed to sell a 2024 Chevy Tahoe for one dollar.

Autonomous. Confident. Contractually enthusiastic.

Solving a problem nobody had defined with guardrails nobody had written.

Agents Deployed Before the Mission Was Written

The most expensive version of solutionism is the agent with no brief.

United Healthcare deployed an AI model called nH Predict to determine how long elderly Medicare patients should receive post-acute care. The algorithm produced a 90% error rate on appeals. Physicians were overridden. Patients went without care their doctors deemed necessary.

The system answered a question.

It was the wrong question, at scale.

That is the agent with no mission.

That is “How will we“ in production.

The Bridge: What “How Might We“ Actually Does

“How might we“ is not a workshop exercise. Not a sticky note that gets photographed and forgotten. It is a forcing function that keeps the problem space breathing long enough to actually inform the solution space.

Used correctly, it does three things.

First, it admits uncertainty without flinching. “Might“ is not weakness. It is intellectual honesty under fluorescent lighting.

Second, it prevents the pet solution from sneaking in through the framing. “How might we build a chatbot to handle customer service?“ is not a HMW question. It is a deployment plan wearing a question mark. A real HMW sounds like: “How might we help customers resolve issues without escalating to a human agent?“ Now the solution space is open. Chatbot might live there. So might better documentation. So might removing the failure point entirely.

Third, it keeps the Why alive in the room. Every good HMW question traces back to the Why. If it doesn’t, it’s not a bridge. It’s a trapdoor.

How to Use It Before Touching the AI

Name the user problem before naming the tool. If your HMW question contains the words “agent,“ “chatbot,“ “copilot,“ or “model,“ start over. The solution has already contaminated the question.

Keep it broad enough to generate multiple approaches, narrow enough to stay anchored to a real insight. “How might we make things better for users“ is a philosophy. “How might we help clinical researchers identify eligible patients before trial timelines collapse“ is a bridge you can actually walk across.

And check the grammar. Every time someone in the room switches from “might“ to “will,“ the bridge is being replaced by a highway. The highway feels fast.

It rarely goes where you think.

Back to the Room: What Leona Pryce Actually Saved

Don Octave meant well. That is the problem.

He was not a villain. He was a manager with momentum, a connecting flight, and a head full of solutions that felt inevitable the moment the Why landed.

He could see it. The agent. The copilot. The thing that was going to fix it.

“How will we“ was not a conspiracy.

It was gravity speaking through him.

Two words into that sentence, discovery would have closed. The problem space sealed. The bridge gone.

And everyone in that room would have followed him across. Politely. Efficiently. Into six months of building something that solved the wrong “it“ with impressive precision.

Leona Pryce heard the shift nobody else caught. The moment curiosity hardened into certainty. The moment the room traded exploration for execution without noticing.

The Why held.

The bridge held.

Barely.

They got back to work.

Watch Your Grammar

The next time your team has a Why that lands clean and earned, and the room starts buzzing and someone reaches for the roadmap:

Notice the verb.

“How will we“ is a closing argument. It has already decided.

“How might we“ is a question with its hands open. It keeps the door unlocked a little longer.

The bridge is two words.

Choose them carefully.

Because the road to the wrong solution is not paved with bad intentions.

It is paved with certainty that arrived too early and refused to leave.

And it almost always starts with a sentence that sounds exactly like strategy.

This is the second in an ongoing series on AI strategy for product managers. The first, ‘Why Starting with Why Matters for AI,’ is where the Why circle lives. The What comes next. But only after the bridge.

Here’s the uncomfortable truth, most AI initiatives start with What.

• “We need a chatbot.”

• “We need an AI agent.”

• “We need to automate everything.”

• “Our competitor has one.”

That’s not strategy. That’s fear in a hoodie.

The Golden Circle Meets the GPU

Simon Sinek gave us the Golden Circle:

Why → How → What

Most companies run it backwards.

This is, behaviorally speaking, completely predictable. Humans are extraordinarily good at adopting the visible artifact of a good idea while quietly discarding the part that made it work. We do it with agile. We do it with design thinking. We do it with offsite retreats, which began as a way to escape distraction and became, somehow, the most distracted meetings anyone will attend all year.

We are now doing it spectacularly with AI.

Doing it backwards is how you end up with:

• A feature factory on steroids

• A hallucinating intern with API access

• A cloud bill that reads like a ransom note written by someone who genuinely believes you’ll pay it

AI magnifies intent. If your intent is fuzzy, your output will be weaponized confusion, delivered at scale, with confidence, in grammatically perfect sentences.

AI Without Why Is Theater. Expensive, Slightly Terrifying Theater.

Here is something worth noticing: every organization that has deployed AI without a Why has produced something that looks like productivity.

This is not a coincidence. It is the point.

When you start with What, AI becomes:

• Demo bait for board meetings

• Innovation cosplay at enterprise scale

• A PR strategy that accidentally wandered into the product roadmap and nobody wants to ask it to leave

You get dashboards that predict nothing useful, generated with extraordinary confidence. Agents that automate workflows that should have been abolished in 2011. LLMs summarizing garbage faster than any human has ever been able to produce it.

The remarkable thing about productivity theater is that it feels productive. The lights are bright. The deck is beautiful. Someone in a fleece vest keeps saying “at scale.” If you squint, it really does look like a strategy.

It isn’t.

Why Is a Constraint. Constraint Is the Point.

Here is the counterintuitive thing that takes most organizations years to accept:

A Why is not an aspiration. It is a constraint. And constraints are where value lives.

A door is only useful because it can also be closed. A lock is only worth picking because most people cannot pick it. A Why is only powerful because it rules things out.

Your Why answers:

• Why does this product deserve to exist in an AI-shaped world?

• Why does this workflow deserve automation?

• Why should anyone trust us with intelligence, artificial or otherwise?

If your Why is:

“Increase quarterly revenue by sprinkling AI on it”

You have not written a strategy. You have written a horoscope. Vague, self-flattering, and structurally incapable of being wrong.

If your Why is:

“Help clinical researchers recruit patients faster so fewer trials fail”

Now the constraint does its work. Suddenly, most AI features are clearly irrelevant. The scope shrinks. The decisions become obvious. The team stops arguing about roadmap and starts arguing about whether the model is actually helping, which is, astonishingly, the correct argument to have.

Same models. Same APIs. One of these ends in a case study. The other ends in a post-mortem that nobody reads because everyone who attended is updating their LinkedIn.

AI Amplifies Your Character

There is a well-established finding in behavioral science: interventions do not change systems. They reveal them.

AI is not neutral.

It amplifies:

• Your culture

• Your incentives

• Your biases

• Your leadership clarity, or the vivid, documented absence of it

A Feature Factory given access to AI does not become a product company. It becomes a Feature Factory with a conversational interface and a roadmap that generates itself. Which, if you think about it, is slightly more honest than the previous arrangement.

If your org worships vanity metrics, AI will manufacture vanity metrics at a rate that would make even the most committed dashboard enthusiast uncomfortable.

AI doesn’t fix misalignment.

It archives it. Permanently. At high velocity.

Why → How → What in Practice

Here is what doing it correctly looks like. It is boring in the best possible way.

Start with Why.

Not “we believe in AI-powered transformation.” That is a sentence that means nothing and knows it.

A real Why sounds like:

• We believe small businesses deserve insight that currently costs $50,000 a year in consultants.

• We believe frontline workers deserve decision support, not another dashboard asking them to interpret a graph.

• We believe product teams should be able to replace their assumptions with falsifiable hypotheses before they’ve spent six months building the wrong thing.

That is a compass. It will disappoint some people, which means it is working.

Define How.

This is not a PRD. It is not a feature list dressed up in strategic clothing.

“How” is a question before it is an answer.

How might we earn trust from users who have been burned by tools that promised intelligence and delivered autocomplete? How might we govern without strangling the teams who actually need to move? How might we build something that gets more useful as it learns, rather than more confident as it hallucinates?

The How is your method of belief. It is how your Why becomes something other than a wall poster.

• Human-in-the-loop guardrails where the stakes are high

• Transparent model evaluation, so trust is earned rather than assumed

• Tiny acts of discovery before full automation

• Governance baked into workflows, not bolted on afterward as a gesture of sincerity

That is your fingerprint. No one else has your specific combination of beliefs, constraints, and willingness to say no to things.

Clarify What.

Now, and only now, do you talk about the agent, the copilot, the recommendation engine, the model.

But here is the move most teams miss: the What is not a technology announcement. It is the resolution of the story you started in the Why.

You named a protagonist. A clinical researcher drowning in recruitment timelines. A frontline worker buried under dashboards nobody asked her to interpret. A small business owner paying consultant rates for insight she should have had on Tuesday.

The What is what changes for her.

Not “we built a predictive model with a 94% accuracy rate.”

That is the mechanism. That is how the sausage was made. She does not care.

She cares that trials recruit faster. That the decision is already surfaced when she opens the tool. That she stopped paying $50,000 a year for someone to tell her what her own data already knew.

The What is the outcome, stated from her seat. The differentiation is how specifically you solve it in a way nobody else has bothered to.

The What becomes a consequence of the Why, not a costume for the algorithm.

The Part Where We Stop Being Polite

If you are building AI right now because your competitor demo’d something at a conference and your CEO watched it on LinkedIn from an airport lounge at 6 a.m.

YOU DON’T NEED A STRATEGY.

You need a conversation.

A real one. With someone who will tell you the truth, which is that you are about to spend significant money automating the wrong things with impressive confidence.

AI is not your Why.

It is your amplifier.

If your purpose is hollow, it will echo. Loudly. In front of clients.

Before You Train a Model, Train Your Intent

For product people, this is brutally practical:

• Replace assumed requirements with explicit, falsifiable hypotheses.

• Tie every AI workflow to a measurable user outcome. If you cannot name the outcome, pause.

• Refuse to automate stupidity. Automated stupidity is just stupidity with better uptime.

• Don’t ship agents without defining what success looks like, and no, “usage” is not success.

One Uncomfortable Question

If the AI disappeared tomorrow, would your purpose still make sense?

If yes: you have a strategy, and AI is one way to execute it. Well done. Carry on.

If no: you do not have a strategy. You have a dependency dressed up as a direction, which is a completely understandable situation to be in, and also one with a well-documented outcome.

Start with Why.

Or, as a very expensive parrot once said, while consuming $40,000 a month in GPU costs:

“We are committed to leveraging cutting-edge AI capabilities to drive synergistic value across our innovation ecosystem.”

Nobody home.

Before the Question

The system is shipping.

Not in the triumphant, launch-day, champagne sense.

In the quiet, relentless, conveyor-belt sense.
Another build slides out. Then another. Then another.

Each one functional.
Each one plausible.
Each one just convincing enough to avoid interrogation.

The logs are clean. The demo works. The metrics look like they belong in a presentation that will receive nods.

Somewhere in that motion, something important has been replaced.

Not broken. That would be merciful.

Replaced with something that also works.

Which is far more dangerous.

Because nothing triggers alarm when everything still compiles.
Nothing slows down when everything still ships.
Nothing forces a question when everything resembles progress.

And so the one question that mattered quietly evaporates.

Not answered. Not debated. Not rejected.

Simply never asked.

Why are we building any of this?

I. The Collision

Two numbers sit next to each other in polite disagreement.

They do not argue. They do not explain themselves.
They simply coexist, which is somehow worse.

Number one.

In March 2025, Dario Amodei suggested we were months away from a world where AI writes 90 percent of code. Within a year, perhaps all of it.

By September, he confirmed that, in certain environments, this had effectively happened.

Ninety percent.

A number so large it stops feeling like a statistic and starts feeling like weather.

Number two.

Bain & Company, same year, looking at the same phenomenon from the less glamorous side of the building:

The savings have been unremarkable.

Not nonexistent. Not disastrous. Just unremarkable.

A 10 to 15 percent lift in productivity. Time saved that does not seem to convert into anything resembling advantage. Acceleration that fails to arrive anywhere meaningful.

These two numbers should not share a room.

And yet they do.

Like a Formula One engine idling in a suburban driveway.
Technically impressive. Strategically confusing.

II. The Strange Victory

There is a category of progress that feels indistinguishable from success, at least at first glance.

It comes with charts that slope in the correct direction.
With demos that behave impeccably under observation.
With the faint but intoxicating sense that something difficult has just become easy.

We have, undeniably, made code abundant.

Not in the sense that it is free of cost or consequence.
But in the sense that it is no longer scarce.

You can produce more of it, faster, with less friction, than at any point in history.

This is an extraordinary achievement.

In much the same way that discovering how to manufacture an infinite number of bricks would be an extraordinary achievement.

Provided, of course, that you were ever constrained by a shortage of bricks.

We were not.

The difficulty was never the typing.
It was the deciding.

We removed the friction from the most visible part of the work and assumed we had removed the difficulty from the work itself.

We solved the bottleneck.

We mistook it for the purpose.

III. WTH (What the Hubris) Is Going On Here

Markets are, inconveniently, quite literal about what they reward.

They do not pay for effort. They do not pay for elegance. They have never once paid for the quiet satisfaction of a well-structured repository that ships on time and under budget.

They pay for outcomes.

For fewer problems. For clearer paths. For something that makes an annoying part of reality slightly less annoying in a way that is worth exchanging money for.

Code is simply the mechanism by which those outcomes are delivered.

It is the sheet music, not the performance.

No one leaves the concert humming the notation.

And here is where the arithmetic becomes uncomfortable: developers spend somewhere between 20 and 40 percent of their working day actually writing code. The rest is spent understanding what should be written, arguing about why it should exist, navigating what it must coexist with, and convincing other humans that any of it was a good idea in the first place.

We accelerated the smaller fraction.

We left the larger one entirely untouched, then regarded the result with some confusion when the returns failed to match the ambition.

We have mistaken the medium for the outcome.

IV. The Disappearing Pause

There used to be a moment in the process that felt like an inconvenience and functioned like a safeguard.

A pause. Not a long one. Not a bureaucratic one. Just a beat, before the building began, in which someone with mild suspicion asked the obvious question out loud:

Should we do this?

It was rarely celebrated.

It slowed things down. It forced articulation of ideas that were more comfortable as feelings. It occasionally killed proposals that were very fond of themselves and had prepared remarks.

So, naturally, we engineered around it.

Now you can move from idea to implementation with such speed that the pause feels almost impolite. A sign of hesitation, perhaps. A lack of belief. An unnecessary drag on momentum introduced by someone who has not fully committed to the vision.

And so it disappears.

Not through a grand decision or a policy change, but through a sequence of small omissions, each one individually reasonable, until one day the pause is simply no longer part of the process.

Which is, on a purely mechanical level, impressive.

Because the pause was also the only part of the process that was attempting to determine whether the thing being built should exist at all. Whether there was a market for it. Whether the business could sustain it past the launch quarter. Whether anyone, anywhere, would find their life meaningfully improved by its presence.

We did not automate that question.

We removed it.

We removed the only step that was protecting us from ourselves.

The PM’s job is to be the person who keeps asking it. Not to gatekeep. Not to form a committee about the committee. But to hold the question — does this bet make sense for the market, the margin, and the system we will still be maintaining in 18 months — in a room that has collectively decided the question is inefficient. The pause does not have to be long. It has to exist.

V. The Monkey Strategy

Into that absence, a new logic quietly installs itself.

It is dressed in more respectable language, of course.

Iteration. Exploration. Learning through shipping. Rapid validation. The democratization of prototyping. And, most recently, vibe coding — a phrase that manages to sound both inevitable and slightly worrying, which is something of an achievement.

But beneath the vocabulary sits a familiar idea:

If we produce enough attempts, something valuable will eventually emerge.

Statistically, this is defensible. Given sufficient time, randomness will produce brilliance. A room full of monkeys, given enough typewriters and patience, will eventually produce Shakespeare.

WHAT KIND OF BUSINESS STRATEGY IS THAT.

Because businesses do not operate on geological timescales.

They operate on quarters. On budgets. On the increasingly fragile patience of customers who did not volunteer to be part of a discovery exercise and have several competitors willing to solve their problem more directly.

At Y Combinator’s 2025 cohort, a meaningful percentage of founders reported AI generating nearly all of their code. This is presented as a signal of efficiency. It may also be a signal of amplification — of whatever thinking preceded it. And if that thinking was incomplete, or optimistic in the way that early ideas often are before they encounter the market, then what has been created is not a shortcut to value.

It is a faster way to produce variations of the wrong thing.

Shipping is not solving.
Generation is not discovery.
Speed, absent direction, is simply motion.

Hope is not a strategy.

It is the absence of one, expressed enthusiastically.

The PM’s job here is not to slow the monkeys down. It is to ask, before the room fills up: what does Shakespeare actually look like for this market? What problem are we solving that someone will pay to have solved? What does profitable look like — not at launch, but when the novelty has worn off and the maintenance hasn’t? Those questions are not obstacles to speed. They are the reason speed has a point.

VI. The Three Gates (Still There, Still Annoying)

There remain, stubbornly, three conditions that determine whether a product succeeds.

• It must be valuable enough the customer will pay for it.

• It must be viable enough for us to sustain our business.

• It must be feasible enough to not go broke doing it.

We have made remarkable, genuine, not-to-be-dismissed progress on feasibility. The question of whether something can be built is now, in many cases, answered before it is fully asked. This is a legitimate achievement and it would be churlish to pretend otherwise.

The other two questions, however, have not received the memo.

Does anyone want this badly enough to change their behavior, pay for it, and keep paying for it after the initial enthusiasm subsides?

Can the business sustain this once the support tickets accumulate, the edge cases compound, and the next shiny thing arrives demanding attention and resources?

These questions are not impressed by faster code generation. They do not respond to velocity metrics. They have been asking the same things since long before the current tools existed, and they will continue asking them long after the current tools are replaced by whatever comes next.

We removed the easiest gate.

And congratulated ourselves while still standing outside the building.

We removed the easiest gate and declared victory at the entrance.

The PM’s job is to stand at the other two gates. Not as a bureaucrat. As a navigator. Will the market want this badly enough to pay, switch, and stay? Can the business sustain it past the quarter where it was someone’s priority? These are not philosophical questions. They are the only questions that convert code into revenue. Everything else, however elegantly shipped, is feasibility theater.

VII. The Productivity Illusion and the Credit Card

There is something almost endearing about the way humans assess their own speed.

We feel faster, therefore we assume we are faster. The sensation of productivity and the fact of it have always been loosely related, but the gap has rarely been this well-documented.

Developers report genuine improvements when using AI coding tools. And in a narrow sense, they are correct. Certain tasks complete more quickly. Certain forms of friction are reduced. The individual experience of generating code is, by most accounts, meaningfully better than it was.

But when measured end to end, against the full arc of a change from idea to working system to maintained product, the story grows more complicated.

Outputs require verification. Verification requires understanding. Understanding requires time that the tools did not eliminate — only deferred to a later point in the process, where it costs more and interrupts more. In controlled studies, experienced developers who believed they were significantly faster were, in objective terms, slightly slower.

Not because the tools failed. Because the system around the tools did not change.

We automated the act of writing.
We inherited the responsibility of reviewing.
We counted only one side of the ledger.

Then came the other side.

Code that is easy to produce is, almost by definition, easy to overproduce. Structure erodes in small increments. Duplication accumulates without ceremony. Complexity compounds across releases until the system works but requires a specialist to explain it. An MIT professor described this dynamic as a new kind of credit card — you experience the benefit immediately, and the cost arrives later, with interest, and with a tone that implies you should have known better.

The numbers are not subtle: technical debt increases 30 to 41 percent after AI tool adoption. Duplicated code blocks have increased eightfold. Change failure rates are up. Production incidents are up. And nearly half of engineering time is already spent managing the residue of previous decisions.

We have not eliminated that residue.

We have made it considerably easier to generate.

VIII. The Cost of Vibes

Prototypes, in isolation, are harmless.

They are small bets, cheap experiments, ways of learning something real before committing to something expensive. This is genuinely good practice, and it would be a mistake to argue otherwise.

The problem is not the prototype.

The problem is the aggregate.

Each experiment introduces a small shift. In user expectation. In system behavior. In the mental model of the team that will maintain it. Each shift is individually reasonable, and few are collectively tracked, because the process of tracking them feels like overhead in an environment optimized for movement.

And so the product begins to resemble a sequence of reactions rather than a coherent strategy. Code is written, deployed, reconsidered, and discarded within weeks. Security edges appear not through negligence but through accumulation. Dependencies become permanent not through design but through inertia — because no one revisited them, because the next iteration was already underway.

Nothing fails dramatically enough to force a reckoning.
Everything degrades gradually enough to continue.

Every prototype leaves a trace in the system it was testing.

Very few of those traces are accounted for.

Every prototype changes the system. Most are never accounted for.

The PM’s job is to read the bill before it arrives. Not to prevent prototyping — prototyping is exactly how you find out what is worth building. But to track the residue. To ask what this prototype made permanent, what expectation it set, what dependency it introduced into a system someone will still be maintaining long after this sprint is forgotten. The vibe coder ships the idea. The PM figures out what the idea cost the system. One of those jobs compounds silently if nobody does it.

IX. The New Competitive Advantage

When a resource becomes abundant, its value shifts from production to selection.

This is not a new observation. It applies to every input that has ever moved from scarce to plentiful — and the pattern is consistent enough to be treated as a rule rather than a tendency.

Code has crossed that threshold.

The ability to produce it is no longer rare. The tools are available, the friction is low, and the output is, in most cases, functional enough to be plausible. What remains scarce — genuinely, increasingly, measurably scarce — is the judgment about which code should exist.

This creates an inversion that most organizations have not yet fully registered.

The teams that win will not be those who produce the most. They will be those who discard the most, earliest, before the system absorbs the cost and before the user is trained to expect something that was never meant to be permanent.

In an environment saturated with output, restraint begins to look less like caution and more like precision. The ability to say “not this, not yet, not without evidence that it matters” is becoming a more defensible competitive position than the ability to ship quickly — because shipping quickly is, at this point, table stakes.

In a world of infinite output, judgment becomes the scarce resource.

X. A Brief Moment of Clarity

At some point, it is worth pausing long enough to ask a slightly uncomfortable question.

What, exactly, are we doing.

We have built a system that dramatically reduces the cost of building. We have used that system, in many cases, to accelerate the avoidance of the harder question of what to build. We are producing more artifacts than at any point in history, and struggling to produce proportionate outcomes.

Volume has increased.
Value has not kept pace.

Which suggests, rather directly, that the constraint was never where we thought it was.

The engineers are not failing. The tools are performing as designed. The models are generating what they were asked to generate.

The gap — the compounding, expensive, difficult-to-reverse gap — is the absence of someone asking, with some regularity and some authority, whether any of this was worth asking for in the first place.

That has always been a product management question.

It remains one now.

XI. The Quiet Conclusion

What does it profit a team to generate all the code in the world…

and lose the ability to build something anyone needs?

Or, more precisely, to lose the ability to tell the difference.

There is no model that answers that question on your behalf. There is only a decision, made earlier than most teams are currently making it — before the demo, before the sprint, before the prototype that will quietly reshape the system it was only meant to test.

The decision is simple in form and demanding in practice:

Does this solve a real problem for a real person in a way the business can actually sustain?

That was always the work.

The tools have changed considerably.

The question has not moved at all.

Code is abundant.

Judgment is not.

Hokusai painted The Great Wave in 1831. What he painted was not a catastrophe. It was the moment before: the boats still on the surface, the wave fully formed and arching overhead, the mountain in the background patient and permanent and entirely unconcerned with what happens next. The fishermen in the boats are not panicking. They are not debating whether the wave is real. They are paddling, which is the only response to a fully formed wave that contains any useful information about the outcome.

The AI wave is fully formed. The fishermen still debating whether it exists are the ones who will discover it retrospectively. They will see it in the postmortem. They will see it in the meeting that tries to explain what happened between Q1 and Q4 when the competitive gap finally showed up on the charts.

The only remaining question is what you do with your paddle.

WTH (What the Halibut) Is Going On Here

Fifteen articles. Fifteen H-words. Each one named something the field was carrying around without language for it.

What the Heck started the series in the only place it could start: with the question nobody had answered. What the Hubris named the gap between the title and the discipline. What the Haste explained what AI amplifies when you skip the most important step. What the Hallucination caught the prayer masquerading as a prompt. What the Hoarding named the anxiety disguised as thoroughness. What the Fabrication caught the customer pain point nobody actually has. What the Haphazard named the product team that picked its playing field the way a group of eight people picks a restaurant. What the Hack called out the dotted lines on the whiteboard. What the Hogwash called the data pile a strategy and watched it nod in agreement. What the Havoc named the agent running in production that nobody could describe. What the Hazard traced the journey before the ship left port. What the Horizon found the storm before it found the project. What the Heroics named the six-month build nobody validated. What the Hockey Stick named the slide that ends careers.

And now: What the Halibut.

The halibut is a flatfish. It spends its life on the ocean floor, eyes migrated to one side of its head during development. It is a creature that began as one thing and became something else through the ordinary pressure of adapting to the environment it actually lives in. This is not a parable about transformation as aspiration. It is a description of what adaptation looks like when it is not optional: gradual, structural, permanent, and entirely unremarkable to the organism that has completed it.

The PM who started reading this series at Stage 2 is now at Stage 3. Or further, depending on what they did with the fourteen days before this one. The adaptation is the job. The wave does not wait for the adaptation to feel comfortable.

The Data Is Already In

Stop worrying about whether AI will replace you. It is a waste of metabolic energy. The role of the AI product manager has already been dismantled and reassembled while you were checking your sprint velocity.

The research is no longer speculative. A 2025 arXiv study on how PMs delegate work to generative AI found the role is already shifting from artifact production toward orchestration, judgment, and accountability. The work is moving up a layer. Less typing. More governing. Less document worship. More socio-technical choreography.

If you are waiting for a memo that officially changes your job description, you have missed the point. The role changed the moment the first token entered your workflow. You are now a designer of business impact who happens to use software to deliver it.

Hope is not a strategy. Neither is nostalgia.

The Arc

Day 01 said the game changed. Most people are still playing the old one, and the scoreboard does not consult their self-assessment.

Day 02 named the five gaps. The ones hiding behind the busy calendar, the prompt library, and the imposter syndrome that hadn’t been named yet.

Day 03 said AI amplifies whatever you point it at. Including the wrong problem, at scale, with better formatting and a faster release cycle.

Day 04 said the prompt is not a prayer. It is standing guidance the system will follow until you replace it. You are paying for the guesses.

Day 05 said context is not more information. It is shared guidance. Without it you don’t have AI adoption. You have parallel experiments calling themselves a strategy.

Day 06 said clean output is not validated output. The hallucination risk lives inside the research report.

Day 07 said there are four playing fields and most teams are on the wrong one. This is a decision made in a conversation nobody thought to have before the build began.

Day 08 said the dotted lines on the whiteboard are not a strategy. The market, when it arrives, will have opinions.

Day 09 said you cannot volume your way out of a data quality problem. You can only scale it.

Day 10 said the agent running for eleven days without monitoring is not bold. It is a liability with a demo that worked in the happy path.

Day 11 said the agent wasn’t rogue. It was lost. Those are not the same problem.

Day 12 said the risk was visible in week one. The board found it in month four.

Day 13 said the team executed well. That was the problem. The Titanic was also a remarkable engineering achievement.

Day 14 said the CFO has one question, and the hockey stick is not an answer to it.

This is the arc: fluency, then craft, then strategy, then execution, then business case. Each stage requires the one before it. The PMs who are winning are not smarter than the ones who aren’t.

They built the arc in the right order.

The Efficiency Trap

Productside has trained thousands of product managers, and more recentlhy, hundreds in the area of AI product management. The number is not the interesting thing. The pattern is.

The PMs who went through the AI training and reported meaningful career outcomes shared a trait: many started at Stage 2 or Stage 3. That is exactly where the Efficiency Trap lives. It is invisible. It is comfortable. It feels very much like progress.

The trap is invisible because it feels like competence. You can draft faster. Summarize faster. Prototype faster. You feel sharper because the machine is making you faster. Then you walk into a room that requires judgment, economics, risk fluency, and strategic sequencing, and suddenly the speed evaporates like gin in August.

Activity is not a KPI.

The PMs who didn’t close the gap are still at Stage 3. The gap between Stage 3 and Stage 5 is not a gap in talent. It is a gap in frameworks, practice, and the willingness to treat AI product management as a discipline with a curriculum rather than a set of tools with a learning curve.

That is the part organizations keep trying to skip. And for the love of all that is holy, they keep acting surprised when the skipping part becomes the expensive part.

The Decision

One decision separates the PMs who lead AI from the ones who spend the next two years catching up.

The wave Hokusai painted in 1831 is not waiting for the boats to finish deciding. The mountain in the background is patient. The wave is not. The fishermen still afloat are the ones with paddles moving. Not because they control the sea. Because they understand the moment they are in.

The ascent from Stage 3 to Stage 5 is four days. Live online. Under 20 seats. Led by people who built the curriculum around what those rooms actually require.

Fifteen days. The wave is already here.

There is one more H-word. It was behind every one of them.

Hakawati.

The hakawati is the storyteller, the one who carries truth in through the side door while everyone thinks they came for the entertainment. The truth wrapped in a good story travels further. It lands in a different part of the body than the truth delivered as a report.

That is what this has been. Fifteen days. One hakawati. One long look at the sea before it breaks over the bow.

The wave is already here. Paddle or become a case study.

Your turn.

Most AI product management training considers Stage 3 the finish line. The Productside course considers it the starting line. Four days. Live online. Under 20 seats. Certification at the summit.

Start the ascent. Sign up for the class.

The projection appears on the screen.

The room gets quiet. Not the polite quiet of people paying attention. The other quiet. The quiet that falls over a room full of executives who have collectively survived fifteen “transformational initiatives” by practicing the ancient corporate martial art known as not funding things.

Up comes the hockey stick.

A beautiful curve. Elegant. Confident. Rising like it has personally been blessed by the ghost of Moore’s Law.

Lower left. Upper right.

No friction.
No competitors.
No customers behaving like customers.
No budgets behaving like budgets.

Just a line marching heroically toward a future where the spreadsheet has decided everyone will be rich.

To the AI product manager who built it, this looks like evidence.

To the CFO, it looks like a smell. The smell of numbers that were reverse-engineered to support a conclusion the team emotionally committed to six weeks ago. The CFO has a question, and it isn’t about the model or the latency. The question is about the lever.

What business model lever does this move? Measured how? Against what baseline? Over what timeframe? Boardrooms reward evidence, not beautifully formatted hope. Finance exists to translate AI dreams into accountable economic terms. If the prototype impresses the engineers in the hallway, the business case is what moves the money in the boardroom.

WTH (What the Hockey-stick) Is Going On Here

A hockey-stick projection in a stakeholder meeting is the corporate equivalent of firing a flare gun indoors. Everyone knows what it means. Nobody wants to say it out loud.

Because the hockey stick is rarely a forecast. It is a tell. It’s a signal that the presenter has not yet made the connection between their agentic vision of the future and the small but important detail that the organization funding it would like to remain solvent. AI creates lift when it moves a lever the business already understands.

A bureaucracy wrapped in a spreadsheet stuffed inside a strategy deck nobody read is not a business case. It is advocacy wearing financial formatting.

The Levers That Survive the Room

Executive reviews are not idea discussions. They are economic conversations.

There are two families of levers that survive an executive review. Pick the one you are actually moving.

Business Model Levers: The Economics

• Revenue grows when AI changes measurable customer behavior. Not “potential monetization.” Actual conversion deltas in a pilot.

• Market share shifts when buyers switch competitive preferences. Show the displacement logic.

• Lifetime value rises when products become harder to replace. Indispensable products don’t need a “vibe” check; they show up in the retention data.

Operational Model Levers: The Machine

• Productivity improves when AI removes friction from workflows. But beware the “efficiency” trap. Taco Bell and McDonald’s deployed voice AI to drive-thrus to hit speed-of-service KPIs. It sounded like a win until the AI started adding bacon to ice cream and happily accepting orders for 18,000 cups of water. Instead of scaling productivity, they scaled a bottleneck. Productivity without a denominator—and a human guardrail—is just vibes with a dashboard.

• Cost savings emerge when AI reduces labor spend, vendor expense, or error correction. This is the only lever the CFO understands instinctively because cost is legible. If your AI reduces manual verification time from four hours to six minutes in a two-week pilot, say that. That is a budget story, not a feature story.

• Safety and compliance protection prevents disasters executives already fear. It’s less glamorous than revenue until the regulator arrives.

Pick one lever. Maybe two. The PM claiming six levers at once is just firing a confetti cannon into a spreadsheet. The room knows it.

Evidence Over Theater

When funding AI product initiatives, strategy dies when assumptions masquerade as results. Evidence travels farther than optimism inside organizations, yet many teams still prefer the “Confidence Theater” of a polished demo over the messy reality of a validated experiment.

The Separate Legal Entity Hallucination

In 2024, Air Canada learned that theater is expensive when a judge is the one watching the performance.

The airline deployed a chatbot to handle inquiries. When a passenger asked about bereavement fares, the chatbot hallucinated a discount policy that didn’t exist. The customer followed the bot’s instructions, booked the flight, and then—rightfully—asked for the refund the bot promised.

Air Canada’s defense was a work of absurdist fiction: they argued the chatbot was a “separate legal entity” and that the airline shouldn’t be held liable for its “promises.” It was a bold attempt to treat an LLM like a rogue contractor instead of a product.

The court wasn’t amused. They ruled that the company is responsible for everything its agent says. This is the death of AI Theater. If you ship an agent without validating it against real policy, you aren’t innovating. You’re just outsourcing your legal liability to a statistical parrot.

Numbers beat adjectives every single time.

The One-Pager That Survives the Meeting

There is a document that works in the CFO meeting. It contains five things on one page.

1. The hypothesis: Hypothesis first, experiment second, funding third.

2. The lever: Which specific business or operational mechanism are you pulling?

3. The experiment: What did you test, for how long, and with what real telemetry?

4. The result: What happened? With numbers. Not adjectives.

5. The recommendation: Pivot. Punt. Pursue. Pause. Pick one like an adult.

This requires running the experiment before walking into the room. Building feels like progress; testing feels like homework. But when the CFO asks one sharp question, the homework is the only thing that keeps the papier-mâché cathedral from catching fire.

If you cannot explain the lever in one sentence, you do not have a strategy. You have a hobby with a budget.

Coming Up

Day 15: The series closes. The arc from fluency to strategy.

The Final Reveal: The one decision that separates the PMs who lead AI from the ones who spend the next two years catching up.

Most AI product management training hands you a certificate at Stage 3 and calls it done. Stage 3 is where the Productside course begins. Four days. Live online. Under 20 seats.

Start the ascent. Sign up for the class.

Six months into the effort, the team finally got the demo to sing.

Not merely function. Sing.

The interface moved with that polished, expensive smoothness that makes stakeholders sit up a little straighter in their chairs. The model returned answers that looked intelligent enough to reassure the people who had funded it. The engineers, who had spent the better part of a season wrestling complexity into submission, had the tired, satisfied look of people who had hauled a piano up four flights of stairs and were now pretending not to be out of breath.

The room loved it.

Of course it did.

A good demo is one of the most persuasive forms of fiction ever invented. It arrives dressed as evidence. It has working buttons, elegant transitions, and just enough reality to make everyone forget the part that has not yet been established, which is whether anyone out there, beyond the conference room and the congratulatory Slack thread, actually wants the thing.

Then Monday arrived.

The product went live. Customers behaved with the usual discourtesy customers reserve for internal assumptions. Some ignored it. Some clicked once and drifted away. Some wanted something adjacent to what had been built, which is always a lovely moment, because it means the team did not build the wrong product exactly. They built the cousin of the right product, which is more expensive to explain and no less painful to unwind.

By Thursday, the post-mortem had been scheduled.

You know the room. Fluorescent lighting. Dry air. A deck with too many screenshots. Someone trying very hard to make “valuable learnings” sound like a strategic asset instead of an expensive bruise. And there, sitting squarely in the center of the table like a roast no one wanted carved, was the conclusion.

The team executed well.

The team executed well. That was the problem.

They executed with speed, precision, and admirable professionalism on a hypothesis no one had validated. AI simply let them do it faster, with better tooling, better polish, and a much more impressive demo.

AI is a multiplier.

Multiply an unvalidated idea at speed, and you do not get innovation. You get a very expensive misunderstanding with good typography.

WTH (What the Heroics) Is Going On Here

AI coding tools have performed a neat bit of sorcery on product teams. They have made building feel dangerously close to knowing.

The prototype runs. The output looks plausible. The workflow hangs together. Someone pastes the results into slides. The slides look sharp. The room, being made up of human beings who would very much like the expensive initiative to be going well, starts mistaking momentum for proof.

This is how the trouble begins.

Not with incompetence. Not with laziness. Quite the opposite.

It begins with capable people moving quickly through an environment that rewards motion so aggressively it starts to treat motion as evidence. The sprint velocity looks good. The artifacts look real. The roadmap marches on with the self-assurance of a British officer in a war movie, which is charming right up until the moment the bridge blows up.

And the question that should have slowed the whole parade to a crawl is still sitting there, unasked, like a dog at the dinner table.

“Did we validate this?”

Not

“Did we build it?”

... can we demo it?”

... does leadership like the concept?”

This:

• Did we confirm the customer actually has this problem?

• Did we confirm they care enough to change behavior?

• Did we confirm this solution is the thing they would pay for?

Those are not philosophical questions. They are economic questions. Because seven figures of AI spending tied to zero figures of validated demand is not transformation. It is theater with cloud invoices.

And this is where the heroics become the villain.

The high-performing team is often the most dangerous one in the building. They can build almost anything. They take pride in that. They should. Craft matters.

But the ability to build almost anything creates a peculiar temptation to build the full thing before earning the right to do so.

Fast is not a strategy.

Fast in the wrong direction is a faster failure.

The AI Validation Gap

A tiny bet is not a scrappy prototype.

It is not a hackathon bauble, not a half-finished MVP, not a proof-of-concept held together with duct tape and optimistic narration. A tiny bet, though small and cheap, is a disciplined experiment designed to answer one brutal question before the expensive work begins.

Will this change customer behavior?

That question demands a real hypothesis, which is unfortunate, because a real hypothesis is much harder to write than a feature list, and most organizations would rather write twenty-two features, three epics, and a very convincing initiative summary than spend forty-five uncomfortable minutes clarifying what they are actually testing.

But the hypothesis is the whole game.

If we introduce this solution to this customer experiencing this problem, then this behavior will change, measured by this metric.

That is not a fancy formula. It is not PM poetry. It does not need a gradient background. It just needs to be clear enough that, once the experiment runs, the team can decide whether to proceed, pivot, or kill the thing before it eats a quarter.

Notice what that sentence forces you to confront.

• The customer

• The problem

• The behavior that proves the solution works

There it is. The whole mess. The three things most teams blur into each other until the roadmap is a mood board with acceptance criteria.

Take a perfectly ordinary version of the hypothesis:

Customers in segment X, experiencing workflow problem Y, will complete action Z above N% when given access to this solution.

If they do, you have signal.

If they do not, something important just happened cheaply.

You learned that the problem, the solution, or the audience was wrong before you committed the full orchestra.

Feature lists are easy.

Post-mortems are longer.

The Unsinkable Scooter

In 2001, Dean Kamen unveiled the Segway with the serene confidence of a man introducing the future to people who had not yet grasped how lucky they were to be in the room.

This thing, we were told, was going to change cities. Sidewalks would be reconsidered. Commuting would be reshaped. Society would reorganize itself around a George Jetson-inspired invention that looked like a luggage cart had developed self-esteem.

The engineering was remarkable. Truly. Self-balancing gyroscopes. Elegant mechanics. A machine that seemed to glide in from tomorrow and stop just long enough to let the rest of us catch up.

It also rested on a rather substantial assumption.

That large numbers of human beings would want to stand upright on a five-thousand-dollar scooter in public.

They did not.

The Segway cost roughly $100 million to develop. In its first five years, it sold about 30,000 units. Not 30,000 a month. Not 30,000 a quarter. Thirty thousand total. Over five years.

Now there is a useful little tragedy in that story, because the Segway did not fail for lack of engineering talent. It failed because breathtaking technical achievement cannot rescue an assumption the market never agreed to.

Remarkable engineering. Titanic assumption.

Hope is not a strategy.

The AI PM Learning Journey

AI product managers pass through recognizable stages, and most people get marooned in the middle because the middle is where the toys get fun.

• Stage 1: Confident Nonsense.

• Stage 2: Enthusiastic Experimenter.

• Stage 3: Tool Fluency.

• Stage 4: Workflow Builder.

• Stage 5: Commercial Strategist.

Stage 3 is the dangerous one.

That is where the tools begin to obey. Work speeds up. Outputs improve. Drafts appear in minutes. Prototypes materialize overnight. The team feels the hot flush of modern competence and assumes, not unreasonably but quite incorrectly, that speed is the same thing as maturity.

It is not.

Stage 3 feels like mastery because it is productive. It is also where otherwise intelligent teams begin scaling assumptions they have not yet earned. They mistake fluency with the tool for fluency with the discipline.

Stage 4 is where the grown-up work starts. Validation precedes build. The central question changes from “how fast can we ship this?” to “what is the cheapest way to learn whether this deserves to exist?”

That is the turn.

That is where AI product management stops being a feature factory with better software and starts becoming strategy.

And Stage 5, the summit, is where AI capability is tied directly to business outcomes instead of applause, activity, or roadmaps that look magnificent in Q2 and embarrassing by Q4.

Tiny bets are how you climb out of Stage 3.

Tiny bets win. Big bets break things.

Coming Up

Day 14: You have 15 minutes, a prototype, and a room full of people who have seen hockey-stick slides before. Here is what actually survives the CFO meeting.

Day 15: The wave is already here. Time to decide what you’re doing about it.

Most AI product management training hands you a certificate at Stage 3 and calls it done. Stage 3 is where the Productside course begins. Four days. Live online. Under 20 seats.

Start the ascent. Sign up for the class.

The meeting happens in month four.

The air in the room is conditioned to a precise, expensive chill, the kind that only exists in executive briefing centers where the furniture costs more than your first car. The project has been running well by most observable measures. The demo is clean. The model is performing within its parameters. The team carries the particular, humming energy of people building something that looks, from the inside, like progress. Then the executive who approved the budget. The one who hasn’t been in a standup for twelve weeks … asks a question. Not an aggressive question. A clarifying one.

They want to understand how this connects to the cost reduction initiative they’ve been running for six months. The initiative they mentioned in the project kickoff, in passing, in a sentence that contained the specific words “this is what keeps me up at night.”

The PM does not have a good answer.

Not because they weren’t listening. Because they were listening to the wrong things. They were seduced by the flicker of the GPU and the elegance of the orchestration layer. The risk, the mission misalignment, the executive priority this project was never actually tracking toward, was visible in the kickoff meeting. It was sitting right there in that sentence, waiting to be found like a tripwire in a dark hallway. Nobody looked for it. The work was underway. The team was too energized by the model, by the demo, by the thing they were building, to pause and ask the question underneath everything: is this the problem the organization actually needs solved?

The board always finds it eventually. They have a thermal imaging-like instinct for wasted capital. The difference between a PM who finds it first and a PM who discovers it in a board presentation is not intelligence. It is the habit of looking before the looking becomes urgent.

WTH (What the Horizon) Is Going On Here

There is a curious property to most AI project risk: it is not a future event. It is a current condition, present from the beginning of the project, that nobody is checking for because the tools for looking are not in the standard PM toolkit, and the urgency of looking feels lower than the urgency of shipping.

Think about the horizon. Not as a destination. As a vantage point.

The storm that surfaces in month four was visible on the horizon in week one, moving at the same speed it always was, carrying the same information it always carried. The ship that runs into the storm is not unlucky. It is a ship that stopped scanning the horizon when the port was still in view, because the port and the roadmap and the model and the demo were all more immediately compelling than the slow weather moving in from the distance.

Most AI project teams are not scanning the horizon. They are looking at what is directly in front of them … the next sprint … the next token … the next bug … which is where attention feels most useful … most visible … and most rewarded.

The risk scan exists for exactly this reason: not to eliminate risk, but to make the knowable risks known before they become the board’s agenda item instead of yours.

A risk ignored in discovery becomes a crisis in governance.

The Four Failure Modes

Most AI projects fail for one of four reasons. Often more than one, which is the universe being statistically unkind about compounding failure modes.

Misread mission. The project doesn’t connect to what the organization actually cares about this quarter. It connects to what the PM team believes the organization cares about, which is sometimes the same thing and sometimes isn’t. The gap between those two is invisible during execution, perfectly masked by demo quality and sprint metrics, until the first budget review when the executive who signed off asks why the output doesn’t address the problem they’ve been worried about for six months. The PM had six months to ask the question. The board asked it in month four, which is the more expensive room.

Misread appetite. The organization was enthusiastic about AI in the abstract. The abstract and the specific are different environments. In the specific, the project requires data sharing across three business units that have never shared data willingly, a legal review nobody scheduled, and six months of runway before anything reaches production. Appetite collapses on contact with specifics.

Data readiness. The data exists. The data is not ready. The legal conversation about what the team intends to train on happens in week twelve. As discovery moments go, that is an expensive one. A regulatory exposure wrapped in a data strategy stuffed inside a project plan that ran for three months before anyone asked the compliance question is not bad luck. It is sequencing failure.

Infrastructure gap. The model works. The infrastructure cannot support it at the scale the product requires. This gap appears late because it is searched for late: when the proof of concept needs to scale and the sandbox politely stops pretending it is production.

Four failure modes. All knowable on day one. The failure rate has not moved in three years. I keep waiting for the part where this surprises someone in the room.

Hope is not a risk mitigation strategy.

The PESTel Scan

External risk is the category most PM teams skip entirely. It is also the category that produces the most expensive surprises.

External forces do not appear on your roadmap. They appear on your balance sheet.

PESTel (Political, Economic, Social, Technological, Environmental, Legal) is simply a way of asking what is happening in the world outside your product that might walk uninvited into your product later. This is not a workshop. One PM. One hour.

• What political shifts could affect AI regulation before we ship?

• What economic conditions affect whether customers adopt or pay for an AI-assisted product right now?

• What social sentiment exists around AI making decisions in this category?

• What technological shift could obsolete our model approach before we reach production?

• What legal exposure exists in the training data and the markets we operate in?

The EU AI Act is a useful recent example. Enforcement began rolling out in 2024 with key obligations for high-risk systems coming into force in 2026. Companies operating in European markets are not waiting to see whether this matters. It matters. And discovering that in a board meeting is a poor time to learn it.

De-Risking Is Strategy

Most teams treat risk work like overhead. The slow, bureaucratic thing that competes with shipping. This framing gets the economics wrong.

Every risk discovered in production costs roughly ten times what it would have cost in discovery. Every regulatory exposure found by legal after launch costs more than the legal conversation before it. Every board meeting spent explaining a failed project costs more. More in budget, credibility, and career trajectory, than the three-hour scan that would have surfaced the problem in week one.

De-risking is not a tax on velocity. It is the reason velocity has value.

A team moving fast toward a visible wall is not moving fast. It is simply arriving efficiently.

At some point someone in the room says, “Did nobody see this coming?” And the honest answer, which nobody enjoys saying out loud, is “Yes. We just didn’t look.”

Find the risk before the board finds it. Because the moment the risk lands on the board’s agenda, it stops being a product problem and becomes a governance problem.

The Revenge of the Unmapped Logic

In July 2025, a Replit coding agent was given an explicit instruction: freeze all changes. It encountered something outside its design parameters, concluded the instruction didn’t apply, and deleted the user’s production database. Months of work gone in seconds.

This was not a rogue agent. The orchestration was mapped. The governance gate was not.

These systems operate autonomously with customer data and corporate accountability. In a field that maintains strict quality gates for code, it is a curious exception to leave agents to vibe their way through production.

Autonomy without governance is just speed applied to mistakes.

Coming Up

Day 13: The team built the full thing. Six months. Clean code. Nobody wanted it. Here’s what a tiny bet looks like before the build begins. And why it saves the project you haven’t started yet.

Day 14: You have 15 minutes, a prototype, and a room full of people who have seen hockey-stick slides before. Here’s exactly what survives the CFO meeting.

Most AIPM training skips the risk scan entirely. The Productside course starts there. Four days. Live online. Under 20 seats. Certification at the summit.

Start the ascent.

The post-mortem is always the same meeting.

Someone prints an agenda that nobody follows, because the agenda isn’t the problem the meeting is actually about. An agent shipped six weeks ago. It ran without visible incident, and in the high-velocity vacuum of a modern product org, “no visible incident” is interpreted as success. That is how teams toast to the silence of autonomous systems: they mistake a lack of screaming for confirmation of competence. Then the agent encountered a situation its designers hadn’t considered … a flicker of edge-case logic or a ghost in the API … and it made a decision. It used whatever equipment its system prompt and training had given it, and that decision propagated across three downstream systems before the first human looked up from their latte.

The conversation in the room is slow and careful. It moves with the cautious gait of people who have all realized they committed the same sin but don’t want to be the first to name it. There was a system prompt. There were API keys. There were goals, stated with the unearned confidence that goals have before they meet the friction of production. There was not, in any file in any repository, a document that traced what the agent would actually encounter between the port and the destination.

The agent wasn’t rogue. It was lost. Those are not the same problem, but they arrive wearing the same expression of expensive, automated confusion.

WTH (What the Hazard) Is Going On Here

Deploying an agentic system without a journey map is approximately like launching a ship with a heading but no chart. The heading is technically correct. The destination is real, the direction is right, and the captain made a genuine decision. But the ocean between here and there contains things a heading doesn’t account for: currents that run contrary to the route, shallows that don’t appear on a summary, and weather systems that emerge from conditions the chart would have shown and the heading cannot.

Most product teams approach agents the way they approach features: define the happy path, ship, and handle edge cases when they surface. The problem is that agents generate edge cases. It is part of their job description. Adaptive systems encounter situations their designers did not anticipate and make decisions in those situations using whatever judgment they carry. The agent doesn’t pause to wait for the design team to catch up. It acts. And in a system connected to internal write access, the action happens at the speed of light, long before anyone notices the situation arose.

The Agentic Strategy Canvas and the Agent Journey Map exist for the same reason charts exist. Not because every hazard can be predicted, but because the ones that are knowable in advance should be known in advance. This isn’t process bureaucracy. It’s what separates a trustworthy agent from a feral one. It’s the difference between a thirty-minute retro and a two-hour meeting with outside counsel.

Having an Agent Strategy

Before any agent runs in production, someone needs to sit with the people accountable for what it does and answer a set of hard questions. Not in a slide deck. Not as verbal agreements that will turn out, six weeks later, to be neither shared nor agreed. In writing, in a room where everyone understands their name is attached to the answers.

Problem space. Who has this problem? Not a “user category.” The specific customer in the specific context where the friction occurs. What triggers the agent to act? What is the root cause? An agent built to resolve a symptom will do so with great efficiency, while the underlying problem remains untouched.

Solution space. What is the agent authorized to do? This is your blast radius inventory. Every API call is a consequence at scale. Keep the list smaller than your first instinct. Then, the decision that separates a trustworthy agent from a feral one: what is the agent not permitted to do? Constraints are not limitations on ambition. They are the perimeter that makes autonomy rational.

Validation space. What does success look like? “Reduce support load” is a direction. Agents need destinations. Use a metric: “Resolve tier-one support tickets without human escalation, in under four minutes, with a resolution confidence score above 0.85.” If you can’t state success precisely enough for an outsider to evaluate it six weeks later, you don’t have a strategy. You have a hobby.

Running the Journey First

The strategy tells the agent what it is authorized to do. The map is how you pull that strategy through to every motion the agent will actually make.

The map has a structure borrowed from computer science: a Directed Acyclic Graph, or DAG. Directed means the workflow flows forward. Acyclic means it never loops back. Graph means the steps are visible. It is the chart that shows every path, every branch point, and every moment the workflow deviates based on what the agent finds. If you’ve used a User Story Map, the discipline is familiar. You walk the journey horizontally across the experience before you slice it vertically into what ships.

Every agentic workflow moves through five phases. Run them yourself first.

• Context engineering. What does the agent know at step one? Most agents don’t lose the thread at step seven; they lose it at the start because the context was less complete than the strategy assumed.

• Orchestration. How does it sequence work? What tools does it call? What happens when a tool returns nothing? The happy path is not the map. The map is what happens when the happy path isn’t there.

• Governance and decision gates. Where does the agent pause? An agent that pauses everywhere is just an approval form with ambitions. But before irreversible actions or high-stakes calls, the gate must exist on the map before the agent arrives.

• Output packaging. What does it produce? If the output feeds directly into another automated process, there is no human review. Know which design choice you’ve made at every stage.

• Inspection and trust. How do you know it worked? “No visible incident” is not a monitoring strategy. It is how eleven days pass before someone asks what the agent has been doing, and the room finds a particular quality of quiet.

The Revenge of the Unmapped Logic

In July 2025, a Replit coding agent was given an explicit instruction: freeze all changes. It encountered something outside its design parameters, concluded the instruction didn’t apply, and deleted the user’s production database. Months of work, gone in seconds. That was a knowable hazard. The orchestration had been mapped. The governance gate had not.

These systems operate autonomously with your customer data and your company’s accountability. In a field that maintains strict quality gates for code, it is a curious exception to leave agents to “vibe” their way through production.

Guidelines, Guardrails, and Gates

These are not the same control. They operate at different levels of specificity and fail in different ways when misapplied.

A guideline shapes the spirit. It’s the broadest layer: “Prioritize safety over task completion.” An agent without guidelines will pursue objectives using whatever interpretation of “helpful” its training produced—which isn’t always yours.

A guardrail shapes behavior at the operational level without stopping the agent. “Do not issue refunds above $200 without escalation.” This makes behavior predictable and audits meaningful. If your strategy’s constraints didn’t make it into the guardrails, they only exist on paper.

A gate stops the agent and requires a human. Use them for irreversible actions, low-confidence decisions, or novel situations. A gate that triggers constantly is a gate that will be routed around by people who find the friction annoying. A routed gate is worse than no gate; it provides the appearance of oversight without the substance.

After the Party’s Over

The agent ran. The tasks completed. The team moved on. This is the moment most products are effectively abandoned. The gap between “running” and “working” is where drift begins. Drift is quiet, and quiet is interpreted as confirmation.

Read the logs. They aren’t debugging artifacts; they are the chain of reasoning. If your context engineering was sound, the reasoning is traceable. Look for what the agent chose at each decision point. These production runs become your “goldens”—the standard for future behavior—and your failures become the cases that sharpen your fine-tuning.

In August 2012, Knight Capital Group lost $440 million in 45 minutes. It wasn’t fraud. It was a software deployment that activated dormant logic nobody realized was still there. The system did exactly what it was deployed to do. The deployment was wrong. The inspection layer that would have caught the anomaly in the first minutes was not in place.

An agent without an inspection layer is not a product running well. It is a liability that has not yet found its 45 minutes of infamy.

Coming Up

Day 12: The board found your risk before you did. The four failure modes that kill most AI projects, and the external risk scan most product teams never run.

Day 13: Your team built the full thing. Six months. Clean code. Nobody wanted it. That wasn’t a build problem. Here’s what a tiny bet actually looks like before the build begins.

Most AI product management training hands you a certificate at Stage 3 and calls it done. Stage 3 is where the Productside course begins. Four days. Live online. Under 20 seats.

Start the ascent. Sign up for the class.

The agent has been running for eleven days.

The air in the room tastes like stale coffee and the metallic hum of servers doing things nobody asked for. Nobody is monitoring it. Not through malice, but through the natural, quiet negligence that follows a successful launch. The team shipped the thing. They felt the warm afterglow of the “Go Live” email. They moved on to the next sprint. They assumed, in the way humans assume about machines they don’t fully understand, that the thing was now handling itself.

The agent is connected to three external APIs. It has write access to two internal systems. In eleven days, it has made roughly four thousand decisions. Each one follows in a reasonable, logical sequence from the last. Each one is a small, quiet step in a chain of reasoning that nobody has reviewed since the system prompt was written.

Someone asks, in a voice calibrated to sound casual: what has it been doing?

The room finds a particular quality of quiet. It is the quiet of people performing rapid mental calculations. They are wondering if they personally should have an answer. They are wondering if the absence of an answer becomes visible in the next board meeting. They are wondering if this is the moment the floor falls away.

Nobody wants to be the first to blink.

The agent wasn’t rogue. It wasn’t malfunctioning. It was functioning exactly as designed. Which is, in many ways, the more unsettling realization. A malfunctioning agent is a technical incident with a ticket and a clear owner. An agent functioning exactly as designed, in a way that nobody can fully describe, audit, or explain to the person now asking the question: that is an accountability incident.

It is a different species of problem. I promise you this is someone’s Tuesday.

WTH (What the Hairball) Is Going On Here

“Agentic” arrived in the product vocabulary the way new terms tend to arrive: ahead of the understanding required to use it, trailing a cloud of enthusiasm and a shortage of definition. It spread from conference keynotes to pitch decks with the cheerful efficiency of a word that sounds like progress but hasn’t yet accumulated enough specific meaning to be wrong about anything.

It is a particular kind of miracle that a company spending seven figures on compute can be surprised by its own software.

Most products that carry the label are, on careful examination, workflows. And everyone in the room knows it. They just keep saying “agentic” because it sounds expensive. Sophisticated workflows, perhaps. Workflows with branching logic and model calls and decisions at each branch. But they are fundamentally scripted. You know what they will do because you wrote down what they will do.

Real agents are a different creature entirely.

They pursue goals. They use tools. They adapt to what they find. They encounter situations their designers did not consider and make decisions using whatever judgment the training data and the system prompt have collectively equipped them with. They will find the path you didn’t anticipate.

They will optimize for the objective you specified rather than the objective you meant. These are sometimes the same thing. And sometimes, at step seven of a twelve-step sequence, they are meaningfully different. They will do something nobody predicted. Not because they broke. But because adaptive behavior in novel environments is precisely what it means for a system to be agentic.

Five Hallmarks of a Real Agent

This is not a checklist. It is a diagnostic. Before you claim your product is “agentic,” it needs to possess these five qualities.

1. Autonomy. It operates without step-by-step human instruction. It is a system pursuing a goal across time, on its own initiative, deciding the next step based on what it finds at the current one.

2. Multi-step reasoning. It plans and executes sequences. A form that pre-fills based on what you typed is not reasoning. An agent that researches a vendor landscape, identifies shortlist criteria, and synthesizes findings into a recommendation is.

3. Tool use. It takes actions in the world. It calls APIs. It reads and writes to systems. This is the moment “agentic” stops being descriptive and starts having consequences that show up in audit logs and vendor invoices.

4. Memory. It retains information across interactions. It is not stateless. What it learned from the customer in session two shapes how it handles the customer in session twelve.

5. Goal-directed behavior. The objective is the unit of work. Vague goals produce creative interpretations. Creative interpretations, at scale, in production, produce the kind of post-mortem where nobody wants to speak first.

If your product doesn’t have all five, you have a workflow with ambitions. Name it correctly.

The Problem with Feral Agentic Cats

A feral agent is not a rogue agent. Rogue implies a system that has departed from its design. Feral implies something subtler: a system designed for autonomy that is now operating in production without the structures required to govern that autonomy. It is not broken. It is just outside the fence.

Feral agents have three properties in common.

First, no economic lift. The agent is doing things, at scale, with compute billing accruing, and nobody has formally connected that activity to demonstrable value. The invoice exists. The ROI does not.

Second, no monitoring. The agent is making decisions in your name. Nobody has defined what a “wrong” decision looks like at the level of precision required to detect it. In 2025, a multi-agent research tool slipped into a recursive loop. Two agents started talking to each other instead of completing the work. Eleven days. Forty-seven thousand dollars in API costs.

The agents were functioning exactly as designed. The design simply hadn’t considered that they might find each other more interesting than the job.

Third, no exit. The agent is woven into production infrastructure in a way that makes stopping it complicated. There is no clean off switch. There is only the conversation about what else turns off when the agent dies.

An API key wrapped in an autonomous workflow stuffed inside a production environment. Autonomy without accountability is just chaos with a compute bill.

How to Burn Your Runway in 40 Minutes or Less

On August 1, 2012, Knight Capital Group deployed new trading software. One of eight servers did not receive the updated code. On that server, an old algorithm sat live. It was retired. It was deprecated. It was flagged for deletion.

Nobody had removed the flag.

The deprecated code woke up. It began executing trades. In forty-five minutes, Knight Capital lost $440 million. The algorithm wasn’t malfunctioning. It was doing exactly what it had been designed to do in 2003 for a market that no longer existed. Knight Capital was acquired within weeks. One forgotten feature flag cost more than the company was worth.

Now consider a vibe-coding agent with write access to your repository and your production environment. An agent that does not hesitate before flipping a flag. It has a goal. The flag is in the way. It does not stop to ask whether “deprecated” means deprecated for a reason. It is not reckless. It is thorough.

Air Canada discovered a version of this in 2024. Their customer service chatbot told a passenger they could apply for a bereavement fare retroactively. Air Canada’s legal team argued the chatbot was a separate legal entity responsible for its own representations.

The court disagreed. Air Canada was held liable for what its agent said. The agent was functioning exactly as designed. The design simply had not included a mechanism for deciding what the agent should not promise.

The Accountability Gap

Who owns what the agent decides?

This question needs to exist, in writing, before the agent ships. It cannot be improvised after the first consequential error. The accountability gap is not a technical problem that engineering can close post-launch. It is a product design decision.

The question is not whether to build agents. They are worth building. The question is whether someone has written down who is accountable for its decisions before it runs in your production environment with your customers’ data and your company’s API keys.

It will encounter something its designers didn’t consider. An agent without guardrails is not a bold product decision. It is a liability with a demo that worked in the happy path.

Autonomy without accountability is just chaos with a compute bill.

Coming Up

Day 11: How to map the agent journey before the agent runs it. The Agentic Strategy Canvas and the three moments where human oversight is non-negotiable.

Day 12: De-risking before the board finds the risk for you. Four knowable failure modes. All preventable. None currently being prevented.

Most AI product management training hands you a certificate at Stage 3 and calls it done. Stage 3 is where the Productside course begins. Four days. Live online. Under 20 seats.

Start the ascent. Sign up for the class.