Product Principles 101 for Product Teams

13 years back (it is 12 January 2022 today) I was working on an online learning product where we had a particularly contentious product decision. When teachers conducted a public online class, students (13-17 years old) from across the world could join it by creating an account. Now, while in a class, should we allow students to check out other students’ profiles and add them to their network? On its surface, this could result in network effects (this is when FB was all the rage). However, it could also be a privacy nightmare. There were strong arguments on both sides. As the debate raged over a period of time, people became increasingly attached to their point of view and the debate reached all the way to the CEO. Do you have similar stories? Have you seen any of these in your products:

• Do you see conflicts in prioritization?
• Do most of your decisions go all the way up to executives?
• Do several deadlocks become discussions of anecdotes?
• Do competing objectives derail the aesthestics of your product?

I learned a key lesson from this product debate and seeing how our CEO resolved it. The CEO explained who we were, what we stand for and what we should do in this situation. I or the CEO did not know it at that time, but the CEO defined and explained the product principle to make this product decision. I’ve learned about product principles a lot more since then. This post captures some of the lessons.

What are product principles?

Product principles are the constitution of your product and the constitution comes from your fundamental values. It defines every decision and action a product team makes:

• Defining goals for your product - check
• Writing your PRD - check
• Defining the milestones - check.

Your principles ensure your product embraces and maintains your key values. Product principles are essential guidelines that help teams evaluate work across functions as well as up and down the decision-making chain, by ensuring all work ladders up to the organization’s ultimate goals. Your product emerges from your prioritization which emerges from a model - which includes not just impact but also principles. Improve your product principles - written and unwritten - improve your prioritization. Codify them, enforce them, guard them! ~Ethan Eismann, VP of Product Design on Product Principles at Slack

Let us look at a hypothetical example of a product principle at this stage -> “Be completely transparent to customers”. We will use this example a little later.

It is also useful to call out what product principles are not.

• Product principles are not quantitative (they are qualitative) and hence, can't be your KPIs or metrics.
• Product principles are never complete. They are like your north star - forever aspirational, forever work in progress.
• Product principles are not your functional / non-functional requirements. Product principles don't tell you what to build but how to build it.
• Product principles are also not your design / brand principles.
• Product principles are not your company’s mission, product vision, and goals. This can work the other way around (eg: Apple) where product principles are integrated into the mission or goals.

Why should you use product principles?

Product principles are best used when you have to decide where your heart and head diverge. You should be able to point to a product principle (or two). Product principles help product teams to make decisions fasterFor instance, if you’ve selected “Be completely transparent to customers as a principle, you would veer towards showing taxes on the hotel listing page rather than wait for the checkout page.

You’d also make accessing current discount codes easy rather than hidden away somewhere. You will have consistency and focus in your decisions and your teams will align faster. Product principles exist to inform execution and are best thought of as a checklist to help anticipate and direct feedback to features you’re building.

Brainstorm, debate, argue, spend countless nights discussing your product principles. It makes the execution and alignment easier once you have them.

Who is it for?

Product principles are for product teams - PMs, engineers, designers, researchers, analysts, QA, data scientists, customer success execs, sales professionals, marketers.

Product principles are useful not just at a whole product (company) level but each product unit or even long running product can have a product principle. The hierarchy would then be as follows:

Whole Product (Company Level eg: Gojek) -> Product Group (Transport, Food, Logistics etc.) -> Product Area (Dynamic Pricing)

As you move from the company level to the product area level, you want to add specificity while avoiding contradiction. In our example, you can’t have complete transparency to customers at the whole product while having (say) abstract the details at a product area level.

Some teams use ‘product tenets’ when describing principles for product areas. When working on a PRD, technical spec or design spec for a feature in a particular product group or product area, product tenets can help guide and explain why some decisions were taken.

Examples of Product Principles

Intercom:

• Think big but start small
• Ship to learn
• Design from first principles
• Read more on Intercom's Product Principles here

Slack:

• Don’t make me think
• Be a great host
• Prototype the path
• Don’t reinvent the wheel
• Read more on Slack's Product Principles)here

Box:

• Product principle 1: Protect our customers’ data above all else Versus: Focusing on revenue monetization The tradeoff? Expense.
Product principle 2: Make content infinitely better when in Box Versus: Creating a homogeneous experience across repositories The tradeoff? Transferability.
• Product principle 3: Be insanely simple Versus: Be highly functional while sacrificing simplicity The tradeoff? Feature density.
• Product principle 4: Build horizontal software for the masses Versus: Specialized vertical solutions The tradeoff? Industry specialization.
• Product principle 5: Focus on building out network effects Versus: Solutions for single enterprise instances The tradeoff? Tech scalability issues (and time).
• Product principle 6: Think 10X Versus: Being incrementally better and executing a fast-follow strategy The tradeoff? Quick iteration and releases.
• Product principle 7: Partner deeply. Don’t underestimate the power of neutrality Versus: Trying to own the full stack The tradeoff? Loss of neutrality.
• Read more here on Box's product principles

More product principles here at Thoughtspot and Gitlab

Drafting Product Principles

1. Start with your product. Make sure you have a product vision and/ or mission. Also, take time out to draft the value proposition as well. It is important to be absolutely clear on what core value you will provide to your customers. Talking with users candidly can help you best understand their needs, wants and desires. Engage a cross- functional mix of your product team to contribute to this discussion.
2. Start with a all the principles team can think of. Your principles should reflect your organization's approach in considering its users’ most fundamental needs, wants and desires. takes in considering its users’ most fundamental needs, wants and desires. They should map back to not just the product you want to build, but the experience you want to deliver, and ultimately the company you want to be.
3. Redraft the principles. Make sure your principles are concise (only a sentence) and that they are broadly applicable (all functions). You should stress test these principles with actual key product deadlocks of the past few months - do they help or do they not. Discard/ redraft at this stage. As would be evident, this is the critical stage of drafting product principles. You can use a template from the above examples. Typically, the principle should be self-explanatory - however, you may flesh it out with a few points/ trade-offs/ explanations as well.
4. Cut the principles to 5 (plus mins 2). This is a good thumb rule. Most product organizations keep somewhere between 3-7 product principles. If you've more, figure allied themes and consider drafting a generic principle. Eventually, you'll have to prioritize with your team.<
5. Evangelize and adopt. Once you've defined your product principles make sure you evangelize them carefully. At Gojek, you can access product (and design) principles via a quick Slack shortcut. All product reviews start with product principles. Initially, you may also see good success by getting volunteers to spread each principle across teams and functions.
6. Get feedback. The volunteers will evangelize and get feedback on a specific principle they pick. They will come back and share practical difficulties. I've heard feedback on the lines of 'too long to remember', 'not used many times' etc. Also, be on the lookout for situations where product principles did not help. Principles are a living instrument - a cross-functional team should help evolve product principles.

The Principles Debate: Product vs Process

If you’ve been following the principles above, you may have noticed that they belong to two distinct categories - one clearly describes the product attributes directly while the other describes the process attributes. I’ve seen teams spend considerable time debating this point.

For instance, look at these set of principles:

• Don’t make me think (Slack)
• Protect customers data at all costs (Box)
• Merchants are the gateway to customers, so our products must “wow” the merchant (Pay.com)

Now, look at these principles:

• Don’t reinvent the wheel (Slack)
• Think 10X (Box)
• Design from first principles (Intercom)

As you can see, the first set of the principles directly translate to the product attributes (eg: customer transparency, sense of security) while the latter describe the process attributes (eg: 10x thinking, start small). Is one better than another?

While most product principles veer towards the process (e.g. Intercom, Gitlab - perhaps because they help the teams with day to day decision making and execution), my recommendation is that teams connect principles to their customers i.e. they work on thinking/ drafting keeping customers in mind. Principles should describe how does the customers/ users experience with the product change if the teams followed that principle. I like the Box.com template of product principles. It defines both, the principle and the trade off, clearly. The principles are written keeping the customers and clear value proposition in mind. As often, the final word on this comes from Marty Cagan:

“Product principles refer to the nature of the product you are building, and they help you to get a much clearer picture of what you believe in and what is important.”

The Final Word

There are two main ways to settle a debate. One is quantifiable impact. The other is going back to our principles to remind ourselves who we are, what we stand for and how we want to make a dent in the universe. I’ve seen product principles help teams that I have been a part of by scaling decision making, providing consistent value proposition and creating a shared understanding of how to build products. If you are drafting product principles for your organization, product group or product area - I’d love to talk to you. I am at @vikramadhiman on Twitter.

Thank you Mayank Jainfor generously reviewing the drafts of this post.