Product Policy

Once a team settles on what to build, a second kind of question shows up right behind it. What should the screen say when the intended action can't go through? If two rules apply at the same moment, which one wins? What happens to the people who were already using the old version of the feature? Every feature drags twenty of these along with it, and almost none of them make it onto the agenda of the meeting where the feature was decided. They aren't visible on any screen, and most of them describe situations that come up rarely.

Pagedeck ran into this when it let paid teams reduce their seat count. A team paying for twelve seats could drop to eight, and nothing anywhere said what happened to the money already paid for the four seats they gave up. Theo thought the natural reading was to credit the unused portion against the next charge, so that's what he built. Sofia told her accounts that the new rate would apply from the next renewal date. The support teammate who picked up a ticket about it offered to refund the difference. One question, three answers, and all three went out to customers as the company's position.

It didn't take long for the three to collide. A customer who trusted the support answer waited for a refund that never arrived and instead found a slightly smaller invoice the following month. When they wrote in again they pasted the earlier email back into the thread, and from that point the work was no longer deciding what the rule should be. It was deciding how to walk back something that had already been promised in writing.

The problem wasn't that someone got it wrong. It was that there was no place where the answer lived. A product requirements document (PRD) covers what a team is building this time and why, which leaves little room for rules of this kind, and a specification, which describes screens and behavior in enough detail to build them, stops at the edge of the screens being built. These rules also outlive the features they came from. The seat-reduction screen gets built once; the question of what happens to the money when seats go away gets asked every week for years.

Product policy is the proposal to pull those rules out and keep them in one place. It groups them by rule rather than by feature, and it spends more lines on the paths that aren't normal than on the one that is.

Everything filed under product policy belongs to a single group: the pieces a policy document is made of. The three follow the order in which a rule actually gets built. First you fix the conditions that must not be broken, then you find the situations where those conditions get shaky, then you decide what the product does in those situations. Skipping ahead usually means starting at the third one, which leads to patching whatever happened to come up this week and accumulating handling rules that contradict each other.

1. Business rule — a condition that must hold in the domain the product operates in. "Only one coupon applies to an order." "The number of paid seats can never be lower than the number of people actually invited." These aren't matters of taste or negotiation, which is what separates them from the other two. Breaking one means the money stops reconciling or a contract gets violated, so the product has to block it even where it is technically possible.
2. Edge case — a situation that comes up rarely but causes trouble if nobody defines it. Dropping to eight seats when nine people have already been invited. Hitting cancel on the exact day the card is charged. Partially refunding an order that had a coupon on it. These show up in maybe three orders out of a thousand, which is why tests rarely catch them and customers usually find them first. The way to hunt for them is to walk the normal flow one step at a time and, at each step, try a quantity of zero or the maximum, a time that lands exactly on a boundary, and the same action happening twice at once.
3. Exception policy — the decision about what the product does once the flow has left the normal path. Retry a failed card three times at three-day intervals, switch the account to read-only if none of them work, and stop retaining the data thirty days later. Steps and deadlines belong together in that sentence. If an edge case is the question, this is the answer, and an answer without deadlines isn't one. "Retry when a payment fails" leaves how many times and until when to whoever writes the code, and it quietly drops the question of when to tell the customer.

Finding those three is half the work. The other half is writing them down in a form someone else can act on without asking. Open any single policy document and five slots should be filled in.

1. Scope of application — how far the rule reaches. Does it bind the free plan? Are enterprise contracts an exception? Does one country work differently? One sentence covers it: "applies to customers on a paid team plan billed monthly." Anything outside that sentence goes in a different document rather than a footnote in this one.
2. Conditions and outcomes — the body of the rule. Put the condition on the left ("when seat count is reduced") and the outcome on the right ("credit the remaining balance against the next invoice"), and lay them out as a table. Keep one condition per row, because that's what lets you change one row later. Bundle two conditions into "when seats are reduced and fewer than fifteen days remain," and moving the day threshold to seven shakes the seat rule along with it.
3. Precedence — which rule wins when two apply at once. If an enterprise contract carries its own discount and a coupon also comes in, an undefined answer means a developer decides it at the keyboard. Writing "the contract wins" once settles every later combination of the same shape.
4. Effective date and retroactivity — when the rule starts and whether people already in that state fall under it. This is the slot most often left empty when a policy changes, and leaving it empty means the person who paid yesterday and the person who paid today get treated differently. The choice is usually between applying the new rule to everyone and compensating the few who lose out, or letting existing customers keep the old rule until their next renewal.
5. Change history — one line per change, saying when and what and why. If the reasoning needs more room than a line, keep a decision record alongside and leave only the date and a link here.

Some of these rules eventually have to be restated as promises to the customer, and those move into the terms of service. Refund conditions and data retention windows work that way, because failing to honor them turns into a dispute rather than a bug report. The two documents describe the same facts for different readers, and editing only one of them puts the product's behavior and the company's promise out of step.

"There's no policy for this, so I blocked it my way for now. Tell me what it should be and I'll change it."

Someone hit a missing rule mid-build and made a temporary call, and is handing the decision back to the people who should have made it.

"A customer is asking whether reducing seats gets them a refund. Where in the policy doc do I look?"

Checking the written answer before saying anything to the customer, because if the answer isn't there, one more rule is about to be invented on the spot.

"Let's leave that out of scope this time. But let's still decide what screen they see when it happens."

Not building it now, while acknowledging the situation will occur anyway, so the behavior at least gets defined.

At Pagedeck the document came into existence the week the team reopened the seat-reduction feature. Mia listed the three answers that had already gone out to customers side by side and closed the question in a single two-hour meeting. Theo said which of the three was actually implementable given how the billing provider handles partial periods. Sofia put on the table that around ten accounts had already been told something different. Grace pointed out that returning the difference in cash changes how the revenue gets recognized.

They landed on crediting the next invoice. Mia wrote that line, added a retroactive exception saying the ten accounts already promised something else would be honored as promised, and set the effective date two weeks out. From then on the same question gets answered by three people opening the same document and reading the same line. The effect doesn't come from the rule being right. It comes from there being exactly one of them.

Something else changed once the document existed. A new question of the same shape no longer requires a meeting, only another line. Three months later, when someone asked what happens if an annual customer reduces seats mid-term, Mia added one line under the existing rule saying annual plans reconcile seat counts at renewal, and told Theo. What took two hours the first time takes ten minutes after that.

The most common mistake is treating policy as an implementation detail. None of it shows on screen and most of it describes rare situations, so it reads like territory a developer can settle on their own. But whether a team that drops four seats gets cash back or a credit on the next invoice isn't a question about implementation. It changes how the company recognizes revenue and what it has promised its customers. Hand the decision down and those rules survive only as conditionals scattered through the code, and six months later, when a customer objects, nobody in the company can explain why the product behaves the way it does. Recovering the rule means reading the code and reconstructing it backward, which usually takes longer than deciding it fresh would have. Code records what happens and not why anyone chose it, so the reconstructed rule can't even be sorted into intended or accidental.

The second mistake is treating it as a document that expires at launch. It arrives bundled with the material handed over for development, so it reads as though its job ends when the build does. In practice it gets opened far more often after launch than before it. Support writes answers out of it, sales puts conditions into contracts from it, and legal edits the terms of service against it. Left unmaintained, the document stays frozen at launch while the product's behavior keeps moving. Once the two disagree and support answers from the old rule, that answer becomes the new promise, and the company ends up honoring a rule that exists neither in the document nor in the code. Rules like that are hard to remove, because customers have already been told, and reversing course makes the company the party that changed its story.