What a meeting is actually about

Two PMs were arguing about whether to ship a new field on a sponsor-bank integration spec.

PM A wanted to ship it. Customers had asked for it. It would close a competitive gap.

PM B wanted to defer. Shipping it would lock the platform into a behavior the regulator hadn’t seen yet.

They argued for an hour. The disagreement wasn’t really about the field. The disagreement was about what the integration spec actually promises. If the contract said we expose only fields the regulator has explicitly approved, PM B was right. If it said we expose any field that doesn’t violate published rules, PM A was right. Neither of them had the contract in front of them. It had been written eighteen months earlier, under a different head of product, and nobody had read it in the last quarter.

Once we pulled it up, the argument was over in two minutes. The contract was three sentences.

That meeting is the meeting. It happens five times a quarter on every product team in the world. The productivity loss isn’t the meeting itself. The loss is the eighteen months of feature work that quietly drifted away from what the contract said, before anyone noticed the drift had started.

Screens are cheap

The visible part of a product — the screens, the buttons, the copy — is the cheapest part to change. It is also where most product attention goes.

The expensive part is what sits underneath. The state machine. The error model. The data shapes downstream code branches on. The contract the platform makes with operators, with regulators, with itself.

Once you ship a screen, you can change it. Users adjust. The screen does not expect anything specific from you.

Once you ship a contract, you cannot change it without a migration. Operators expect specific behavior. Regulators expect specific guarantees. Other code expects specific shapes. The contract is what locks in.

The PM craft that compounds is contract craft. Almost nobody is taught it as PM craft.

Where contracts live

Three layers, weighted differently.

The first is between teams inside the company. When the payments team ships a new transaction state, the fraud team gets notified within five minutes. That is a contract. Sometimes it is written down, often it is a Slack message, sometimes it is nowhere at all. When it is nowhere, every release becomes a fight about what was supposed to happen.

The second is between surfaces of the product. The dashboard expects the API to return field X. The mobile app expects the dashboard to expose field Y. The webhook expects both. Implicit contracts here make every refactor dangerous. Explicit ones turn refactors into a checklist.

The third is the most expensive: between the platform and the people reading it from the outside. The bank reads what the platform produces. The regulator reads what the bank produces. The fintech reads what the platform exposes. Each contract is the easiest thing to break by accident, and the most expensive thing to break in production.

The PM who picks up the document before re-litigating the argument, who reads the contract before debating the field, saves the team eighteen months of drift.

The contract as PM artifact

Most PMs ship two artifacts. The PRD, which says what to build. The spec, which says how it should behave.

The PM whose work compounds ships a third: the contract.

What does this surface promise? What does it not promise? Who is reading this promise? When does it apply? When does it stop applying?

The contract is short. Often a paragraph. Sometimes one sentence. It is read more often than the PRD and the spec combined, because every future debate about the surface starts with what did we say this would do.

The integration argument above was won by a three-sentence contract written eighteen months earlier. Whoever wrote those three sentences was the most useful PM on that team for a year and a half. They probably moved on to another company before realizing how much friction those sentences saved everyone who came after.

A working rule

Before arguing about a feature, read the contract.

If the contract does not exist, write it before the argument continues. The act of writing it usually ends the argument. Most arguments are about what was already decided, not about what to do next.

This is not a glamorous habit. It shows up in the meetings that don’t happen because the contract already settled them.

How to write a contract that survives

Four properties matter, roughly in the order they get violated.

A contract is always for someone. A regulator, a sponsor bank, a fintech, an internal team. If the contract does not name its reader, it will drift to please everyone, which means pleasing no one. So the first property is: name the reader.

The second is the negative space. The hardest part of a useful contract is what it does not promise. We will expose this field. We will not guarantee its value at any specific time. We will not preserve it across schema migrations. The negative space is what protects the platform from the future feature that would otherwise quietly violate the spirit of the document.

The third is dating, versioning, signing. A contract without a date drifts. A contract with a date is a checkpoint. The version number is for the moments when the contract changes on purpose, with sign-off, in a planned migration. Contracts that change without versioning are contracts that already broke.

The fourth is length. If the contract is longer than a page, it is actually a spec. The contract is the promise. The spec is the behavior. They are different documents, and conflating them is how teams end up with neither.

The bet

Screens decay. Roadmaps reorder. Strategies get rewritten quarterly.

Contracts compound. The contract you write today, if it is correct and concise, gets read in three years by a PM who has not joined yet, in a meeting you will not be in, about a problem you did not anticipate. They will pull up your three sentences, and the meeting will end in two minutes.

The work you can do today that pays back in three years is contract work.

Most PMs do not get to do it because they are too busy shipping screens.

Make the time.