Product principles

Product principles are the core values and guidelines that inform how a product team makes decisions. They provide direction when specific rules don't exist, helping teams navigate ambiguous situations consistently. Principles express what the product stands for, what trade-offs it makes, and what matters most when choices must be made.

Why it matters

Product teams face countless decisions that aren't covered by explicit requirements. Should this edge case favor simplicity or completeness? Should we optimize for new users or power users? Should we ship faster with known limitations or wait for perfection?

Principles provide answers. Instead of debating each decision from scratch, teams can refer to shared principles. "Our principle is simplicity over completeness, so we should handle this edge case the simple way." Principles accelerate decisions and create consistency.

What good principles look like

Effective product principles share certain characteristics.

Opinionated. Principles should take a stand. "We value quality" isn't useful because everyone values quality. "We ship early and iterate rather than waiting for perfection" takes a position.

Decision-relevant. Principles should help make actual decisions. If a principle never influences a choice, it's probably too vague to matter.

Memorable. Long lists of principles don't stick. Five to seven core principles that people can actually remember are more useful than twenty no one references.

Clear in trade-offs. Good principles often express preference between two valid options: "X over Y." This acknowledges that both matter while clarifying priority.

Example product principles

Different products embrace different principles.

"Simple over complete." When forced to choose, we build something simple rather than something comprehensive. Features don't launch until we've removed everything unnecessary.

"Fast for the common case." We optimize for the 80% use case even if it makes the 20% edge case harder. Power users can adapt; regular users shouldn't suffer.

"Transparent by default." Information should be visible unless there's a specific reason to hide it. When in doubt, share more rather than less.

"Customers over competitors." We focus on solving customer problems rather than matching competitor features. Our roadmap follows customer needs, not competitive anxiety.

"Mobile first." Every feature works well on mobile. If it can't work on mobile, it waits until it can.

"Opinionated defaults, flexible configuration." We make decisions for users rather than forcing them to configure everything, but we allow overrides for those who want control.

Principles vs. rules

Principles and rules serve different purposes.

Rules are specific and prescriptive: "All text must meet WCAG AA contrast ratios." Rules tell you exactly what to do.

Principles are general and directional: "Accessibility is non-negotiable." Principles guide judgment in situations rules don't cover.

Products need both. Rules provide clarity where it matters; principles fill the gaps between rules.

Creating product principles

Developing principles involves several steps.

Examine past decisions. What choices has the team made? What trade-offs recur? Past decisions reveal implicit principles worth making explicit.

Identify tensions. Where do values conflict? Speed vs. quality? Simplicity vs. power? Principles clarify how to resolve these tensions.

Articulate and refine. Draft principles, test them against real decisions, and refine until they're useful and memorable.

Build consensus. Principles only work if the team agrees on them. Debate and buy-in matter.

Document and share. Principles should be visible and referenced, not hidden in old documents.

Using principles

Principles only help if teams actually use them.

Reference in decisions. "According to our principle of X, we should..." makes principles part of everyday conversation.

Include in documentation. PRDs and design specs can reference relevant principles, explaining why certain choices were made.

Evaluate against principles. Retrospectives can ask whether recent work aligned with stated principles.

Update when necessary. Principles should evolve as products and contexts change. Outdated principles that no one follows should be revised or removed.

Principles at different levels

Principles can exist at multiple levels.

Company principles apply across all products. Amazon's "customer obsession" is a company-level principle.

Product principles apply to a specific product. A B2B product might prioritize power over simplicity; a consumer product might do the opposite.

Team principles might govern how a specific team operates, beyond product decisions.

These should align - product principles shouldn't contradict company principles - but they can add specificity.

Common principle mistakes

Too many principles means no one remembers them. Five strong principles beat twenty weak ones.

Principles no one disagrees with aren't useful. "We care about users" isn't a principle because no one advocates not caring about users.

Principles that aren't followed create cynicism. If stated principles don't match actual decisions, either change the behavior or update the principles.

Principles without trade-offs don't guide decisions. "Quality and speed" isn't a principle; "Quality over speed" is.

Principles and customer feedback

Customer feedback can both inform principles and validate them.

When feedback consistently shows customers value certain things - reliability, simplicity, specific features - those patterns can inform principles.

When feedback conflicts with principles, it's worth examining whether the principle is wrong or the feedback represents an edge case the principle intentionally doesn't optimize for.

Tools like Klero help surface these patterns by aggregating what customers consistently say matters, informing whether principles align with customer reality.