Product principles should have tradeoffs

Taking a principled approach to product development is prudent. Good principles tell us what to do and what not to do; they bring focus.

Too often, teams identify principles that are so obvious they end up meaningless. An example: “Build quality experiences.” Okay, sure. But how is that actionable? Were you previously considering building a low quality experience? Famously, Google has the principle, “Don’t be evil,” but it’s hard to imagine scenarios where a team confronted a crossroads and was brought clarity by this declaration.

Good principles should *not* be self-evident. In fact, the best principles should catalyze debate and disagreement up to the point when the team formalizes alignment.

When principles are opinionated, they bring resolution. They make decision making faster, clearer, and more objective. When Mark Zuckerberg proclaimed in Facebook’s early days, “Move fast and break things” he established that the company valued speed over stability, a tradeoff that helped the company scale (and yes, beget many of its problems). When he amended this in 2014 to the far less pithy, “Move fast with stable infrastructure” and plastered posters that said “Slow down and fix your shit,” it ushered a different reckoning.

A substantive principle relating to quality might be: “A feature isn’t an MVP if it makes the product harder to use.” This stake in the ground suggests that we shouldn’t ship anything if it regresses usability metrics. This would actually be quite bold; many new features bloat products and create new learning curves. But if you align on this with conviction, you can hold the line on new features that are complexifying.

As teams approach roadmapping, reflect on what tradeoffs you’re ready to make. Have the hard conversations to reach alignment now, as you strategize but before picking the tactics, knowing it will accelerate progress later on.