Skip to content
Andrews Dean
← Field Notes
July 8, 20263 minReplacing the spreadsheet

Enforce the rule. Respect the room.

Good products don't just encode the policy. They encode how mature people actually apply it, including when they choose to bend it.

I built a rule into a product, then made it easier to break. On purpose. That one decision is basically the whole job of product.

The clean answer was the wrong one

The policy where I worked: no more than 5% of a team can be nominated for an award in a cycle. Small team, one slot. Bigger team, two.

The obvious engineering answer was clean. Hit the cap, block the nomination. A rule is a rule.

I didn't build it that way, and here's why. I'd watched how the room actually behaves. On the call, when a team hit its cap but someone made a genuinely exceptional case, the group didn't robotically refuse. A senior approver would say "this one's worth it" and own the exception, out loud, with everyone watching.

A speed limit with an officer beside it

Think of a speed limit with a traffic officer standing beside it. The limit holds for everyone, but the officer can wave through the ambulance, in the open, on the record. A hard block is a camera with no officer. It can't tell an emergency from a mistake.

So the cap became soft. A manager can't blow past it alone. But an approver can override, and when they do, the system makes them type a reason, right there, for everyone to see. Same as the room. The exception is allowed. It's simply never silent.

Those typed reasons turned out to be worth more than the audit trail they were built for. Read together after a few cycles, they were a running list of every case the policy hadn't anticipated, written by the people closest to the judgment call. That's better policy feedback than any survey I could have sent.

Let me put the balance plainly, because it's easy to lose one half of it: the rule protects the standard, and the override respects reality. Drop either one and you've built the wrong thing. A doormat with no standards, or a bureaucrat nobody can reason with.

Encode how people actually behave

Good products don't just encode the policy. They encode how mature people actually apply it, including when they choose to bend it.

So where is your product more rigid than the people it's meant to help?

This is the product the essay describes — see R&R App.

product-managementproduct-judgmentpolicydesign

Contact

Let's talk.

If you're building an AI-first product org — or you need someone who can take a vague mandate and return a shipped, adopted product — I'd like to hear about it.

hello@andrewsdean.com · Noida (Delhi NCR), India