My product principles

“More than any other document, a set of product principles can bring together the product team—especially product management, user experience design, engineering, and marketing—and get the team on the same page.”

Marty Cagan, Inspired: How To Create Products Customers Will Love

I’m a big believer in taking the time to define organizational culture. Putting your mission, vision, and values into writing isn’t just feel-good fluff. Done well, it helps the right people find your organization and stay aligned once they’re on board.

After reading Ray Dallio’s Principles, I started thinking about what my product principles were. If you search the web for “product principles,” you’ll find a lot of generic values (“build trust”) and product basics (“start with the problem”). We all want to build trust, and best practices are worth clarifying, but to guide hard decisions and reflect a distinct point of view, principles should speak to tradeoffs (good things that you’re willing to give up) and what makes you different—not just from strawmen but from other well-trained product thinkers.

Here are the product principles that anchor my decisions:

Customer-intimate > customer-obsessed

Don’t build for the vocal minority. Don’t build just to close a deal. Don’t build for the customer who’s threatening to churn. Build for the market.

Work closely with customers to understand their problems and test your hypotheses, but don’t navigate by them. Be customer-intimate, but idea-led.

Chef’s knife > Swiss Army knife

Most software does more than it should. Be disciplined: nicely say no most of the time and always look for ways to cut functional scope. Yield to complexity as slowly as possible.

Keep it simple

If the product can’t explain itself, it’s too complicated. Do the hard work to make things simple and understand that simplicity begins with product management—not with design. Make it self-explanatory, if not self-evident. 

Make room for craft

Build to deliver value, but don’t sacrifice craft. Leave headroom for code quality. Cut functional scope before pushing back delivery. Push back delivery before releasing something that you can’t learn from. Remember that quality (as measured by reliability and maintainability) is one of the best features a product can offer.

It’s done when it’s dead

It’s not done when it’s launched; it’s done when you kill it. Until then, it’s your responsibility.

#

These principles will seem extreme or even off-putting to some product teams and founders, but the purpose isn’t to win a popularity contest: it’s to align the product team and its closest collaborators regarding intrinsic value. In my case, it’s to clarify what I stand for and the kind of product culture I want to find (or start).

As is the case with any product artifact, conversations need to happen to translate words into actions and outcomes. What do you think? What resonates? What doesn’t? What are your product principles? Please share your thoughts!