How to make “product principles” more useful

There’s an interesting discussion going on in the Elezea Community about “Product Principles”. What they are for, when you need them, how they can be made more useful, etc. A couple examples given are Intercom’s set of guidelines for making decisions, Dan Ritz’s interface design values and my own company’s values.

The biggest challenge I see with principles like these is figuring out how to make them specific enough to help us make decisions. The further I get into reading Good Strategy, Bad Strategy the more I realize how much we tend to hide behind nice words, when in most cases those nice words don’t actually change our behavior in any meaningful way. For example:

Bad strategy is not the same thing as no strategy or strategy that fails rather than succeeds. Rather, it is an identifiable way of thinking and writing about strategy that has, unfortunately, been gaining ground. Bad strategy is long on goals and short on policy or action. It assumes that goals are all you need. It puts forward strategic objectives that are incoherent and, sometimes, totally impracticable. It uses high-sounding words and phrases to hide these failings.

I fear that “product principles” are prone to be made up almost exclusively of “fluff”:

Fluff is superficial restatement of the obvious combined with a generous sprinkling of buzzwords. Fluff masquerades as expertise, thought, and analysis. A hallmark of true expertise and insight is making a complex subject understandable. A hallmark of mediocrity and bad strategy is unnecessary complexity—a flurry of fluff masking an absence of substance.

I think product principles, in particular, need to be detailed and specific enough so that they affect day-to-day decision making. This is similar to how we should use Personas (and why so many people hate Personas). If you just put a Persona’s face on a coffee mug, that’s not going to be very useful. But if you’re able to say, “this feature would be useful for a persona that’s not in our target market so we’re not going to build it”, that’s an entirely different story.

Which leads me to wonder if what we call “product principles” should rather just be the combination of a well-defined design system and content strategy. HelpScout’s Style Guide immediately comes to mind as a good example of this. Because what are “Product Principles” for if they don’t help us make product decisions?

Do you have thoughts to add on this topic? Join the community.