Product Principles – Examples for Product Managers
Since product development is often a blank canvas (particularly in startups) the sheer number of possible scenarios and opportunities you might want to explore can be overwhelming:
- Should we build a mobile app or not?
- Yes, we’re B2B but are we targeting small businesses or enterprise?
- What colour should our homepage CTA buttons be?
Strategic decisions are fundamental questions of what value your product delivers, to who and why. Tactical decisions are concerned with how you might deliver the answers to those questions.
Principles can help guide both strategic decisions and tactical decisions.
Sure, they’re not the only factor you should consider when making tough decisions, but as both a decision making tool and a tool for inspiring teams as a leader, a set of clearly articulated and regularly updated product principles can massively boost your ability to build winning products.
And with that, let’s explore some examples of product principles that you can use as inspiration for your own.
Examples of Product Principles
Example 1 – Intercom
Intercom is known for its strong product-led thinking – and its principles play an important role in the overall development of its product.
In a blog post outlining how Intercom applies principles to its process, the company explains why principles are so important to the company:
Having clear principles keeps everyone pointed in the same direction, and empowered to move quickly and with confidence.
The company defines principles as a ‘set of fundamental truths or propositions that serve as the foundation for behaviors that give you the results you want.’
But here’s something that’s worth noting: at Intercom, principles apply to different areas of the product organisation, broken down into the following:
- Research and development
- Product design
- Engineering
Intercom’s research and development principles
- Start with the problem
- Think big, start small, learn fast
- Ship fast, ship early, ship often
- Deliver outcomes
Intercom’s design principles
- Connected, modular systems
- Opinionated by default, flexible under the hood
- Follow fundamentals
- Make it feel personal
- What you ship is what matters
Intercom’s engineering principles
- Shape the solution
- Be technically conservative
- Build in small steps
- Keep it simple
- Work with positivity, pride and love
This may seem a little risky but I do see the logic in breaking down principles by group, since the types of decisions an engineering team needs to make will be different to the decisions made in research and development.
Indeed, you may start with company-wide product principles and then decide to get more granular, but then as the company grows, decide to create org-specific principles. The key though, is to ensure the principles are coherent and aligned with one another.
Looking at Intercom’s principles, we can see that whilst they’re specific to each part of the organisation, they compliment each other. Engineering’s principle of ‘building in small steps’ complements design’s principle of building ‘connected, modular systems’ which in turn compliments research’s ‘ship fast, ship early, ship often’ principle.
Consider what would happen if these were in conflict with each other. Allowing different parts of the business to decide on completely incompatible principles clearly seems like a recipe for incoherent decision making.
Example 2 – Slack
Slack’s product principles include the perennial piece of product advice: don’t make me think.
Yes, this is from a now classic book on UX, but it’s still relevant today. Unless of course, the scenario is made better by making a user think i.e. before taking an important action that has significant – potentially negative – consequences, then generally making users think more than they need to is poor UX.
The reference to reinventing the wheel is important too, since this reiterates the importance of component oriented thinking and how this can aid the overall design process. If you’ve already built a bunch of components that do the job effectively, why rebuild them from scratch? Similarly, if users expect a component to behave in a certain way, reinventing the wheel can negatively impact the overall experience.
Why product principles don’t last forever
In a post outlining their approach to product principles, the company makes it clear that at Slack, product principles “always evolve to keep up with the changing ways” the company works and their current customer needs.
This is an important point. It makes it clear that whilst you might pat yourself on the back for creating your product principles, your work isn’t done forever; there will always be further work to do if the assumptions or operating model upon which the previous principles were created have changed.
When to consider re-evaluating your product principles
Here’s some ideas on potential triggers for re-evaluating your product principles:
- Strategic triggers – a major product strategy decision has been made (i.e. to target a new customer segment or pivot to a new business model) which impacts your principles.
- Technical triggers – component oriented design and development was largely made possible by the likes of React making it incredibly easy to build component-based front ends. In this way, technology led to principles based on the assumptions that that technology means it’s possible to build components. New technology can directly – or indirectly – influence product principles.
- Customer expectation triggers – as markets evolve, customer expectations do, too. Take the example of the principle ‘ship to learn’. This is largely derived from MVP / lean startup thinking, and whilst it’s still relevant today, customer expectations are actually much higher than they were 5 or 6 years ago so we may see customer’s willingness to accept a basic MVP continue to decrease over time. With that, this principle could be re-evaluated.
Example 3 – Gusto
Gusto is a HR management platform for payments, benefits and other perks and these principles span across the entire product team.
For the product teams at Gusto, the realisation that the folks who build the product and the folks who use it are human is important.
The company’s co-founder and chief product officer outlined this in a post explaining the principles saying:
Products are human. They mirror the perspectives and quirks of the people who built them. This type of personality-driven product development requires stepping back and determining the values and principles that truly matter to your team.
Of all of Gusto’s 5 product principles, there are two that stand out as principles worth discussing a little more:
- Show users how much we love them
- Be opinionated
Showing users how much you love them
One of the risks with an exercise like developing product principles is that you end up being inwardly focused: you emphasise the processes, tools and thinking you need to build products more efficiently, but you forget about the humans who are actually using them.
At Gusto, they prioritise delight by building features which show users how much the company loves them. An example outlined in their principles document is the employee pay stubs feature. Based on research, the teams found that employee pay stubs were an important, but dull and transactional part of the employee pay system. Gusto took this and designed a pay stub feature that made users feel loved. How?
Companies were given the ability to add a congratulatory personal note to every pay stub.
This worked not only to make employers feel loved but also employees. Employers felt that their needs in keeping staff retained and felt welcome were addressed and employees were given a pat on the back every time they were paid.
Being opinionated
When we spoke to Christin at Shopify during our Product Stacks series, she felt strongly about product principles and spoke about the importance of sometimes having an opinion.
With the rise of user-led research and product development, many teams have taken this as a free pass to sit back and let customers make important decisions on their behalf – without ever having an opinion of their own.
Opinionated software can be a joy to use; when it’s clear that designers and product teams have made decisions that they think will enhance the overall product experience, this can help users – even if they don’t agree with it themselves.
Wikipedia is an example of opinionated software. Instead of sticking to the convention of visually attributing every document change to an individual person, Wikipedia decided to remove the visual representation of ownership which made document reading more pleasurable. This was promoted by the wiki creator Ward Cunningham and without this opinionated design choice it’s unlikely that wikis would be as popular as they are today.
For Gusto, having an opinion means encouraging certain ideas that will make a user’s lives better. This meant building a charity matching feature which allowed workers to contribute money directly from their paychecks to good causes, which companies can then match to show that they care, too.
How to develop your own product principles
So it’s all well and good deciding you want to develop your own product principles and examining the principles of other companies. The question though, is how do you develop your own product principles? Where should you start and what should you include?
Here’s some tips to get you started
Consider your desired outcomes
Principles are designed to make decision making more efficient and to help embed strong, aligned decision making across the entire product org.
An important part of this is considering what your desired outcomes are.
If your desired outcome is teams that ship code regularly, using shared components that make the lives of your customers easier, consider this as a starting point and work backwards.
If your principles don’t align with your desired outcomes, they may not be the appropriate set of principles. Similarly, your vision and strategy help with this too.
Re-engage with your vision and strategy
Strong product principles will align nicely with a company’s vision and strategy.
If your principles feel as though they’re taking your company into an alternative direction that deviates away from your strategy, it may be time for a rethink.
Design principles that aid decision making
Do your principles help or hinder decision making? O
Take Intercom’s design principle ‘Make it feel personal’. How does this help aid decision making? Well, a product team might be deciding how to approach writing API documentation. One option is to copy and paste from a template and edit the bits that relate to Intercom. And another option might be to build a personalised set of API docs using a CMS that uses dynamic variables which make the overall experience
Use principles
What’s the point in having principles in the first place if you’re never going to use them?
Once you’ve established your product principles which may or may not be different for each part of your product org, consider how your principles will ultimately become part of your product process.
Opportunities for referring to product principles could include both strategic and tactical decisions so that leaders and product team members (engineers, designers, PMs) all use their principles for different parts of the product lifecycle.
Iterate
Finally, whilst you might celebrate creating and embedding principles into your product culture. Intercom sets its re-evalution cadence to once every 1 – 2 years. You might adopt something similar, but whatever your cadence is, you’ll recognise that every now and then you’ll need to iterate on your principles.
Nothing stays static for long in product. And your principles will need to adapt accordingly.
Podcast
Product Stacks Podcast by the Department of Product. A deep dive into the tools, frameworks and processes used by product managers from top companies.
Product launches, news and analysis delivered to your inbox. Weekly.
