From Platitudes to Power: How to Write Principles That Settle Debates
The 2 AM Decision
The Slack notification chimed at 2:17 AM. It was from the on-call engineer. "Critical failure in the checkout flow. Payments are down." For the small e-commerce startup "Wander," it was a DEFCON 1 situation. The Head of Product, Maria, the lead engineer, and the CEO jumped on a video call, their faces illuminated only by their monitor glow.
The problem was a third-party payment provider's API. The immediate fix was messy: they could revert to their old, clunky, but reliable payment system. It would take about an hour. However, the old system didn't support Apple Pay, which now accounted for 30% of their revenue and was a key feature for their most loyal customers. The alternative was to try and patch the new system, a high-risk maneuver that could take hours with no guarantee of success.
The CEO was firm. "We're losing money every second. Revert it. Get the sales flowing again."
The lead engineer pushed back. "If we revert, our best customers are going to wake up to a broken experience. We promised them a seamless checkout. This is a huge step backward."
They were at an impasse, paralyzed by two competing, valid priorities: restore revenue immediately vs. protect the core user experience. The team had goals—"Increase revenue," "Improve user satisfaction"—but those goals were now in direct conflict. What they lacked was a tool to navigate the conflict itself. What they lacked were principles.
The Emptiness of "Good" Principles
Setting goals is the first step. But goals are destinations; they don't tell you how to drive. Principles are the rules of the road. They are the guide rails that help a team make decisions when goals conflict, as they inevitably do.
The challenge is that most teams write bad principles. They fall into the trap of creating statements that are well-intentioned, universally agreeable, and ultimately useless. Consider a common product principle:
"Do the right thing for the user."
Who could argue with that? It sounds noble. It feels right. But in the 2 AM crisis call at Wander, it offers zero guidance. The CEO could argue that restoring the ability for any user to pay is "doing the right thing." The engineer could argue that protecting the experience for the best users is "doing the right thing." The principle is a platitude, not a tool. It's a statement of virtue, not a guide to action.
How BigTech Forges Principles into Tools
This is where the most effective product organizations separate themselves. In BigTech, principles are not motivational posters; they are working components of the product development machine. They are forged into tools through two key processes:
Formal Integration: Principles are a mandatory section in core product documents. In a Product Requirements Document (PRD) at Google or a design spec at Meta, you are required to list the principles governing the project. This forces the author to think through their trade-offs before writing a single feature requirement. It's the first line of defense against vague thinking.
Ruthless Application: Principles become the language of critique. In product reviews and design sessions, when a debate arises, the most common question is, "Which of our principles does this decision support?" This immediately elevates the conversation from personal opinions ("I like this design better") to a structured argument based on a shared framework. The best teams ruthlessly apply tests—like the one we're about to discuss—to ensure their principles are sharp enough to withstand this pressure.
They understand that a principle that can't survive a debate is useless.
The Litmus Test: The Power of a Worthy Opponent
So, what makes a principle truly effective? Here’s a simple but powerful rule of thumb that the best product leaders use:
The opposite of a good principle is also a good principle.
Let's apply this test. The opposite of "Do the right thing for the user" is "Do the wrong thing for the user." This is obviously not a valid principle for any sane company. Therefore, the original statement fails the test. It doesn't force a choice; it merely states the obvious.
Now, let's consider one of the most famous principles in tech history, from the early days of Facebook:
"Move fast and break things."
Let's test its opposite: "Move slowly and deliberately to ensure stability." Is that a valid principle? Absolutely. It's the guiding principle for companies building medical devices, banking software, or aerospace systems. Because its opposite is not only valid but essential in other contexts, the original principle becomes incredibly powerful. It gave Facebook's engineers license to prioritize speed above all else. It was a clear, actionable guide for making trade-offs. (They later famously amended it to "Move fast with stable infra," a new principle whose opposite is also valid!)
Let's try another, from the payment company Stripe:
"Global from day one."
The opposite? "Focus on a single market first." This is not only a good principle, it's the default strategy for 99% of startups. By explicitly stating "Global from day one," Stripe's principle forces every team to make decisions differently. It's a principle with teeth, precisely because its opposite is so sensible.
A Tale of Two Principles: How Wander Found Its Way
Let's return to our team at Wander, stuck in their 2 AM crisis. After that painful night (they reverted to the old system and spent the next week apologizing to angry customers), Maria decided the team needed real principles.
She proposed two to the team, based on the painful trade-off they had just experienced:
Revenue Health Over Feature Polish: In a crisis, our first priority is to ensure the core business can transact. We can apologize for a degraded experience, but we can't recover from a zero-revenue event.
Power User Experience is Sacrosanct: Our most loyal and engaged users are our moat. We will accept short-term pain and slower growth before we compromise the experience for this cohort.
Notice that these two principles are in direct opposition. They are both valid. A different company could easily choose the other. This is the sign of a powerful principle.
The team debated. The CEO favored Principle #1. The lead engineer and designer argued for Principle #2. The debate itself was valuable, forcing them to confront the soul of their company. Ultimately, they decided that as a premium brand, their long-term success depended on their power users. They adopted Principle #2.
Three months later, a similar crisis hit. A new feature was causing site-wide slowdowns. The immediate fix was to disable it for everyone. But this time, they had their North Star. The conversation wasn't a chaotic argument; it was a focused discussion. "Our principle is 'Power User Experience is Sacrosanct.' How do we live up to that right now?" They quickly decided to disable the feature for new and casual users but leave it active for their power user cohort while they worked on a fix. The principle didn't give them the answer, but it gave them the framework to find it quickly and confidently.
Using AI as Your Principle-Writing Partner
Crafting these kinds of sharp, actionable principles is hard. You can use an AI as a sparring partner to move from vague platitudes to principles with teeth.
Prompt 1: The Platitude Detector
"I am drafting product principles for my team. My company's goal is [Your core mission]. Here is my first draft of principles: [List your vague principles, e.g., 'Be user-centric,' 'Focus on quality']. Act as a skeptical product coach. For each principle, apply the 'opposite test.' Explain why the opposite is or isn't a valid principle, and tell me which of my principles are too vague to be useful."
Prompt 2: The Trade-off Generator
"My product is [describe your product, e.g., 'a project management tool for creative agencies']. My key goals are [goal 1, e.g., 'increase new user acquisition'] and [goal 2, e.g., 'improve retention of existing power users']. These goals often conflict. Generate five pairs of opposing, debatable principles that would force my team to make a clear choice between these two goals. For example, 'New user simplicity over power user functionality' vs. 'Power user functionality over new user simplicity.'"
Prompt 3: The Scenario Tester
"We have decided on a core principle: [State your sharp principle, e.g., 'Emphasize speed over quality for the next six months']. Now, create three realistic, challenging product or engineering scenarios where this principle would be put to the test. For each scenario, describe the situation and the two conflicting choices the team would face. This will help us understand the real-world consequences of our principle."
Prompt 4: The Principle Refiner
"Here is a principle we're considering: 'Move fast.' This feels a bit vague. Help me refine it by asking clarifying questions. For example, ask me: 'What are you willing to sacrifice in order to move fast? Code quality? User research? A/B testing? Cross-functional alignment?' Based on my answers, help me rewrite the principle to be more specific and actionable, such as 'Shipping is better than perfect' or 'Prioritize individual action over group consensus.'"
Conclusion: Principles as a Compass
Goals tell you where you're going. Principles are the compass you use to navigate the turbulent seas of day-to-day development. They are not feel-good posters on a wall; they are sharp, practical tools forged in the heat of difficult trade-offs and integrated into the core of how a team builds.
The test is simple: if the opposite of your principle is absurd, your principle is useless. But if its opposite could also be a valid choice for a different team in a different context, you have found a statement with true power. You have found a guide that will help your team make the right call, even at 2 AM.