Product Principles: Writing the Constitution That Makes Decisions for You

A product principle only earns its name when it forces a real tradeoff — "we choose X over Y, even when it costs us" — and would be genuinely uncomfortable to violate. Statements like "we value quality" or "customer-first" aren't principles; they're values-poster words that no one can act on, because they never say what you give up.

A real product principle is a pre-made decision: it names two good things and states which one wins when they collide. If violating it wouldn't cost you anything or annoy anyone, it isn't specific enough to resolve an actual argument — rewrite it until it does.

What Makes a Product Principle Actually Work

A product principle works when it resolves a recurring argument before it starts, by naming the two things people fight over and declaring a winner in advance. Most "principles" fail this test — they're applause lines everyone already agrees with, so they never actually change what anyone does.

Ray Dalio's Principles popularized a useful definition: a principle is a way of successfully handling a recurring type of situation, applied consistently instead of decided fresh every time. That's the shift to make. A product principle is a decision you've already made, filed away so your team doesn't re-litigate it every sprint.

A working principle has to pass three tests:

• Names a real tradeoff. It picks between two things a reasonable team could want — not between something good and something obviously bad.
• Would sting to violate. Breaking it should cost you a customer, a deadline, or a stakeholder's patience — not just look mildly inconsistent.
• Changes what ships. You can point to a decision that would have gone differently without it.

Compare that to "we're customer-first" or "we value craftsmanship." Nobody at any company would claim the opposite — no one says "we're indifferent to customers" in a planning meeting. A statement everyone already agrees with resolves nothing, because agreement was never the problem; the argument is about what to do when two things customers want conflict with each other.

Amazon's Leadership Principles work as well as they do specifically because several name a real cost. Disagree and Commit doesn't say "communicate well" — it says you can lose the argument, state your objection once, and then execute the decision as if it were your own. That's a tradeoff: your certainty of being right, versus the team's ability to move. Not every organization would choose that trade, which is exactly why it counts as a principle instead of a value.

The Tradeoff Test: How to Tell a Real Principle From a Platitude

Run any candidate principle through one question: what would we stop doing, or whom would we disappoint, if we actually followed this? If the honest answer is "nothing" and "no one," it isn't a principle — it's a description of something everyone already intends to do anyway.

Reed Hastings and Patty McCord drew this exact line in Netflix's widely-read 2009 culture memo, one of the most-cited documents in product and management circles. They separated stated values — the words on the wall that sound impressive in an interview — from actual values, which show up only in who gets promoted, funded, or let go when it's costly to do so. A principle is only real if it's an actual value written down before the pressure hits, not after.

The table below shows five statements that appear on real roadmap decks, next to the tradeoff each one is quietly avoiding.

Notice the pattern: every platitude hides a specific "vs." Naming that "vs." explicitly is the entire job of turning a value into a principle — the rewrite in the next section shows exactly how.

This isn't only a writing exercise. Bain & Company's long-running research into organizational decision-making — the work behind Marcia Blenko and Michael Mankins' concept of "decision effectiveness" — found that how well an organization makes and executes decisions tracks more closely with financial performance than almost any other factor Bain has studied. Vague principles produce vague decisions, and vague decisions are exactly what that research links to weaker execution.

Weak to Sharp: Rewriting a Principle With Teeth

Rewriting a weak principle into a sharp one means replacing an abstract virtue with a named "X over Y," then testing whether a real team under real pressure would actually want to violate it. If nobody would ever want to break the rule, the rule isn't specifying anything yet.

Take a principle nearly every product org has adopted in some form: "We prioritize user experience." It sounds correct, survives every leadership offsite, and changes nothing, because "user experience" isn't a side of any real argument — it's the name of the argument itself.

Here's the rewrite process, step by step:

1. Find the actual fight. Where does "user experience" come up as a disagreement? Usually: adding a requested enterprise setting versus keeping the interface uncluttered for everyone else.
2. Name both sides honestly. The other side is real too — "configurability" or "revenue from a specific account" isn't a strawman, it's a legitimate competing good.
3. Declare the winner, with a condition. State which side wins by default, and what would flip it.
4. Write it as a sentence someone could quote in a meeting, not a document title.

Sharp rewrite: "We default to zero new settings. A configuration option ships only if we can name the specific segment it's for, and we're willing to say no to every other segment that asks for something similar afterward."

That version is uncomfortable on purpose. It means telling a paying enterprise customer no, sometimes despite a salesperson's protest. It means an engineering lead can decline a scope-creeping ticket by citing one sentence instead of re-arguing UX philosophy from scratch. That's the entire value of the exercise: the argument already happened once, on paper — not every Tuesday in a design review.

The same rewrite discipline works on any domain. Here are four more common weak principles put through it.

Deciding which customer request actually counts — the "three or more accounts in the same segment" clause above — is exactly the judgment call a solid Jobs to Be Done practice is built to make less arbitrary. You end up prioritizing the underlying job, not whichever account shouted loudest this week.

How to Write Product Principles Your Team Will Actually Use

Writing product principles that stick is a five-step process: mine your team's real recurring arguments, draft each one as an explicit "X over Y," pressure-test it against a past decision, cap the set at what people can actually recall, and put it somewhere it gets cited, not filed. Skipping the mining step is the most common failure.

1. Mine your last ten arguments, not your aspirations. Look back over a quarter of Slack threads, roadmap debates, and escalations. The recurring fight — not the mission statement — is where your real principles are hiding.
2. Draft each one as "X over Y," never as a single virtue. If you can't finish the sentence "...even though it means we give up ___," it isn't ready to publish.
3. Pressure-test it against a decision you already made. Would the principle, applied honestly, have produced that decision? If it would have produced the opposite, either the principle is wrong or the decision was — figure out which before you ship it.
4. Cap the list at five to seven. Past that, nobody can recall them under pressure, and an uncited principle might as well not exist.
5. Put principles where decisions already get made — inside the spec template, the PR description, the doc your team opens when they're stuck — not on a slide that only surfaces once a year at an offsite.

If the real gap is unclear decision rights rather than an unclear decision itself, that's a related but distinct problem. Bain's RAPID framework — Recommend, Agree, Perform, Input, Decide — addresses who gets to decide; a principle addresses what the decision should be once you know who's making it. They pair well but solve different problems.

This is also where most principle-writing exercises quietly die: the words look sharp on a strategy deck and then never touch a real decision, which is the same failure mode covered in the gap between a strategy deck and daily execution. A principle that only lives in a slide is a vision statement wearing a principle's clothing.

A vision people actually repeat is a different artifact solving a different problem: vision says where you're going, principles say how you'll decide along the way. For how both fit into the rest of the stack — vision, strategy, roadmap, metrics — see the complete guide to advanced product strategy.

Using a Principle to Settle a Live Debate

A written principle settles a live debate by replacing "let's discuss this in the meeting" with "apply the rule and see who it favors" — turning a values argument into a much narrower argument about whether this specific case is an exception. That reframe alone can cut most debates from a full meeting to two messages.

Say your team is mid-debate: Sales wants a custom SSO configuration for one enterprise account closing this quarter. Design and half of engineering say it fragments the settings screen for everyone else. Both sides have already presented their case twice. Nobody's mind is changing in the room.

Apply the sharp principle from the previous section: "We default to zero new settings. A configuration option ships only if we can name the specific segment it's for, and we're willing to say no to every other segment that asks for something similar afterward."

1. Name the segment. Is "one enterprise account" a segment, or a single logo? If it's one logo, the principle already answers no.
2. Ask the forward question. Would you say yes to the next five accounts that ask for the same thing? If the honest answer is no, saying yes now just delays the same fight with worse precedent.
3. Write down any exception you make. If leadership overrides the principle for strategic reasons — a lighthouse deal, a board relationship — that's a legitimate call, but log it as an explicit exception, not a quiet erosion of the rule.

That's the difference a real principle makes: the debate doesn't disappear, but it shrinks. Instead of re-litigating whether user experience matters — settled, in writing, months ago — the team is only arguing one narrow, factual question: is this a segment or a logo? That's answerable in an hour, not a meeting.

Some debates aren't about a single feature at all, but about where you sit competitively — whether a capability is still a differentiator or has quietly become table stakes. For those, a principle needs the situational awareness Wardley Mapping's view of the competitive board provides, before you can even state the right "X over Y."

The same mechanic works on a journey-shaped debate — say, whether to smooth a rough moment in onboarding or invest further downstream where power users churn instead. A principle like "we fix the worst moment in the journey before we polish an already-good one" turns a subjective argument about which team's stage matters more into a lookup against your customer journey emotion curve, instead of a popularity contest between teams.

Making Principles Stick: Where They Live and When They Expire

Principles stay useful only if they're cited at the moment of a decision, not just agreed to once at a kickoff — which means they need a permanent, linkable home your team actually opens, and a standing review so an outdated tradeoff doesn't quietly keep winning. Most principles die from neglect, not disagreement.

A principle written once and never revisited becomes exactly the platitude it was written to replace — everyone half-remembers it, nobody can quote it precisely, and it stops shaping decisions long before anyone formally retires it. Three habits keep that from happening:

• Review on a fixed cadence, not when something breaks. Quarterly is common — check whether the market condition that justified the tradeoff still holds. A principle written for a resource-constrained team of eight doesn't automatically survive a fundraise and a headcount tripling.
• Sunset explicitly. Retiring a principle out loud, with the reason, is healthier than letting it quietly stop being followed while it's still technically "policy."
• Make it citable, not just visible. A principle a PM can paste into a spec's rationale section gets used far more often than one buried in a slide only a VP has open.

Watch for three patterns that quietly kill a principle set: too many (past seven, recall drops and citation stops), too safe (no one has ever been told no by one, so it's decoration), and too static (the market moved, the tradeoff never got re-argued, and the team is now defending a rule that made sense two years ago).

Key Takeaways

• A principle is a pre-made decision. If it doesn't name a real "X over Y," it's a value, not a principle, and it won't resolve anything.
• The violation test is the fastest filter. If breaking a candidate principle wouldn't cost anyone anything, rewrite it until it would.
• Weak principles hide a tradeoff instead of naming it. "Customer-obsessed" and "data-driven" are common offenders — the fix is finishing the sentence "...even though it means we give up ___."
• Five to seven principles, cited constantly, beat twelve principles memorized by no one.
• A good principle shrinks a debate instead of ending it — from "does UX matter" to one narrow, answerable factual question.
• Principles need a standing review cadence and an explicit sunset process, or they quietly rot into the platitudes they replaced.
• Where a principle lives determines whether it gets used — citable inside a spec beats memorable on a slide.