Product Principles

On a team without them, the same argument comes back every quarter. Should new users see every feature or a trimmed-down version? Should this behavior become a setting or stay a single fixed default? More research doesn't settle questions like these, because both sides are right and the real question is which one the team is willing to give up.

So decisions flipped with whoever was in the room. In March the team agreed to keep things simple and removed the option. In July a large customer pushed and the option went back in. Nothing recorded why either call was made, so a person who joined in September opens the argument again from the beginning, asking why it can't just be a setting. The meeting burns two hours for the third time, and the side that wins is usually the side that was loudest that day.

Product principles exist to have that argument once and write down the result. Instead of re-fighting it, the team states which way it goes at a particular kind of fork and pulls out the sentence next time.

A principle is written as a sentence that gives something up. "We choose reliability over speed" names what gets sacrificed inside the sentence itself. A sentence that sacrifices nothing decides nothing in a meeting.

By that test, "we put users first" is not a principle. Nobody in the room will argue against it, so it can't pick between two proposals. "We finish what already exists before we add something new" is a principle. Agreeing to it costs the team two new features this quarter, and that cost is visible to everyone who signed up for it.

Three questions sort the real ones from the slogans. Does the opposite also make sense as a sentence? Does it bind at least one decision on this week's list? Does following it cost something? A sentence that fails any of the three is a slogan.

Writing them takes five steps.

1. Collect ten decisions from the last six months where the team split. Pull them from meeting notes and decision records rather than from memory, which tends to keep only the dramatic ones.
2. For each one, write the two words it split between. Speed and reliability. Flexibility and simplicity. New customers and existing customers.
3. Find the pairs that repeat. If four of the ten split on the same pair, that pair is where this team actually forks.
4. Write one sentence per pair and attach two real decisions as examples. Without examples, six months later everyone reads the sentence differently.
5. Cut the list to somewhere between three and five. Keep twelve and one of them will fit any decision at all, which brings the team back to deciding nothing.

Principles don't stay written and untouched. When a decision contradicts one, the team does one of two things: reverse the decision, or agree the sentence no longer holds and rewrite it. Left contradicted, nobody quotes that sentence in the next meeting.

There are four places principles actually get pulled out.

The first is saying no. A refusal needs a reason, and a reason that rests on one person's judgment is hard to defend. Pointing at a sentence the team agreed on moves the conversation from personal taste to a choice the team made together.

The second is prioritization. When twenty candidates can't be ranked by weighing their value against each other, a principle knocks a few off the list. Put a task that shaves 0.3 seconds off save time next to one that drops save failures from one in ten thousand to one in a hundred thousand, and "reliability over speed" orders them.

The third is design review. When two screens split the room on taste, the principle becomes the thing being judged against. One layout hides three options behind a menu and the other lays them out flat, and whether that counts as an improvement depends entirely on which sentence the team wrote down about flexibility and simplicity.

The fourth is bringing someone new on board. Two years of decisions can't be explained one by one, so the four rules those decisions followed get handed over instead. Someone who knows those four sentences can predict most of the past calls without hearing the story behind each one.

Principles move together with the terms next to them. Positioning, the spot the product means to occupy in a customer's head, has to be settled first before it's clear what can be given up. And once differentiation, the strength competitors can't easily copy, is named, the build-buy-partner call — whether to build something, buy it, or wire in someone else's — falls out along the principles.

"That contradicts our principles. Making it a setting breaks the one about shipping a single default."

The objection rests on a sentence the team agreed to, not on personal preference.

"We have four principles and not one of them touches this decision."

The written sentences aren't doing any work on real calls.

"We'll take the request, just not this quarter. We wrote down that polishing what exists comes first."

This is a question of order, not a refusal, and the order has something behind it.

Pagedeck wrote four principles just after its Series A. Mia laid out twelve decisions from the previous six months and wrote the two words each had split between. Speed and reliability kept coming up, and so did flexibility and simplicity. Those two pairs became sentences, each with one real decision attached as an example.

Since then, when Noa brings two screens to review, she adds a line saying which one adds another setting. With that line on the page, the meeting stops being about which screen looks better and becomes a conversation about whether to keep the principle or break it this once.

The most common mistake is treating principles as company values. Both end up as sentences on a wall, so the mix-up is easy. But values describe how people are expected to behave, while product principles pick between two proposals about the product. Honesty and respect don't separate option A from option B. Blur the two and the wall fills up while the number of sentences anyone can quote in a product meeting stays at zero.

The second is expecting principles to make decisions on their own. "Decided in advance" sounds like it should work that way. What they actually do is narrow the field. If both remaining options sit fine with every principle, the rest is evidence and judgment — and some decisions have two principles pulling against each other. A team that misses this limit ends up in long meetings held hostage to the sentences, and eventually stops trusting them at all.