Working principles for product experiences
How to define working principles for product teams and use them to drive the right experience decisions, faster, by more people.
Working principles help cross-functional teams make the right product experience decisions faster by providing acting as a set of reference points that the team can adhere to. The principles are based on what we learn from shipping, research and internal discussion.
Unlike mission statements and company values, working principles are supposed to change over time. They are supposed to evolve based on new insights we learn as we do more work. They may also help us to actually decide what work we do.
Common product team problems
-
It’s hard to connect daily work with long term mission statements.
People struggle to make explicit connections between their tactical day-to-day work and the larger org-wide or company-wide mission statements. Or to look at it in another way, it can be challenging to work backwards to translate missions into experiences.
-
Team decision making is slow, misaligned or bottlenecked.
Different people in the team make different decisions for different reasons. Even simple decisions take too long. Maybe design or PM are making most experience decisions, so when they’re not available, things slow down. Not having principled alignment up front with teams prevents proper collaboration downstream (e.g. doing roadmapping won’t work unless we’re aligned on Why).
-
It’s hard to know why historical decisions have been made.
People aren’t clear on why certain product decisions have been made. Challenging for people who are already in a team, but even worse for those who are just joining.
-
Fixed principles and values are hard to use for tactical decision making.
It can be hard for companies/orgs/teams to make ‘what we stand for’-type values or principles useful, rather than universally agreeable and therfore a bit useless for actual decision making. Most of these kinds of principles are too abstract to use for day to day product decisions.
-
Product teams are too optimistic.
Many product teams don’t recognise or account for the inevitable cost of their decisions. We’re victims of our own optimistic bias, because we want what we're doing to succeed. Having reference points acting as constraints can help ground our decision making in reality.
How working principles can help
Working principles translate team strategy into the right experiences by helping the team more effectively make the right day-to-day experience decisions.
-
Context and confidence.
They help everyone understand why product decisions have been made before and why we’re making our current decisions now. This is particulary useful context for when new people join the team.
-
Autonomy and pace.
They enable any team member to make better daily product decisions, rather than waiting for more experience-oriented functions like a product designer or product manager to make decisions.
-
Conscious learning.
They help teams track how their point of view changes over time as their learnings deepen. And because those learnings are articulated, they can be effectively shared across organisations.
Example decisions
You and your team may ask yourselves questions like these when creating experiences. You need a point of view to speed up decision making and ensure the responsibility for decisions can be spread accross the team.
-
Should this registration flow be: quick or thorough?
Should we include form fields upfront that will save people time later, or punt on them until later? How should we align field labels?
-
Should this onboarding experience be: self-serve or handheld?
Should we proactively provide suggestions for how to get the most from their account, or only disclose those things when people show intent?
-
Should this viewing experience be: lightweight or rich?
Should we blend different media and create an experience that feels really immersive, or focus on stripping back everything but the written content?
-
Should this editing experience feel: predictable or smart?
Should we help people save time by providing dynamic auto-complete suggestions and elegant formatting, or just stay out of their way?
-
Should this group forum feel: private or open?
What should the default visiblity of a post or group be? How often should we mention audience visiblity of content? How much friction should there be to share content or add/remove members?
-
Should this experience feel: tailored or flexible?
Should we order the menu items to prioritise what we think are the most popular use cases, or order them in a more neutral way?
There are no right or wrong answers to these questions. You may want a bit of both. But typically you and your team will be optimising for one over another, even unconsciously. Recognising this and defining principles is critical because it defines what tradeoffs you’re willing to make and speeds up future decision making across the team.
How to define working principles
The key is to work backwards by documenting decisions your team has already made about the experiences you work on, then define themes based on what you find.
-
Document historical decisions
Run a session with your team to document some key experience decisions you’ve already made. These shouldn’t be a surprise to anyone in the team. See the list of example decisions for reference. You might want to prepare some yourself prior to the session, so the team understands the kind of output you’re looking for.
-
Identify themes
Identify the themes you see in those decisions. Max 10 themes. Seeing these themes should prompt the team to think more deeply about what those decisions actually ladder up to. Iterate/reword the themes until you get team level agreement. Examples: optimising for self-serve over handheld, predictable over smart, large and general over small and specific, lightweight over rich, caring over actionable, safety over transparency.
-
Refine themes into principles
The hard bit: reduce and refine these down to 3-4 crafted themes; few enough so that people can actually remember them. This is best done solo then brought back to the team for review because it involves a fair amount of wordsmithery. For each theme, you want: 1 line heading, short descriptive paragraph, and your list of example decisions from step 1. Then get team level buy in. The themes should feel a bit contentious; make people take notice. A good way to do this is to focus their tone and/or content on what tradeoffs you won’t make.
Fictional example
Imagine we’re building a close-knit photo sharing service specifically for families. There are free and paid versions. Most family members have accounts created on their behalf by a single person who’s in charge of setting up the whole product. We see usage of the product and downloads of the mobile apps vary depending on individual family member intent, digital literacy and perception of value. We’re focussing a lot of effort on ensuring people stay up to date with the latest uploading and commenting activity, particularly via notifications.
-
People value first, product growth second
20% of our paying customers and 40% of our free customers don’t activate their accounts. But we aren’t a growth team intent on prematurely pulling people into the product. Our focus is to slowly prove there’s value in the product by allowing them to use parts of it without having to fully activate their account or download the apps.
Examples
- People don’t have to activate their account to get content updates.
- People don’t have to activate their account to update their subscription preferences.
- People who haven't activated their accounts yet only receive 1 activity digest per day.
-
Predictable, not smart
We want people to know that the whole family will see their photos when they upload them, and for people who are commenting on photos to see the most up to date conversation around a photo. We don’t employ ‘smart’ tricks for reducing notification volume like trying to proactively guess which notifications people might find less important, or grouping multiple comments together into a single notification.
Examples
- We deliver notifications for comments on photos as soon as people leave their comment, even if you’re in the middle of a task like uploading a new photo or commenting on one.
- We always include an upfront note for photo uploaders so they know who will be able to see their content, and a note for commentors about who will be able to see their reply – because not all photos and albums want to be shared to the whole family.
- We don’t give account admins the ability to turn commenting off. Our research proves that preventing free conversation around photos isn’t condusive to the kind of family-oriented environment people expect, and allowing ad-hoc settings changes like these can lead to confusion especially for customers with lower digital literacy.
-
Density over brevity
We’ve learned that people value the nuance in our product and the activity within it (particularly commenting and conversations), so we optimise our notification experience around disclosing as much as possible about content instead of only highlighting certain pieces of content.
Examples
- By default our comment thread notifications will display the full content of each comment, instead of truncated versions, so people have the full context they need to reply. This increases content volume; a tradeoff we’re willing to make.
- For new accounts without much content, we will send a notification for every new piece of content. This will mean a high notification volume. We will work to create more fine grained notification controls over time.
- Notifications are on by default, and account admins will not be able to disable them. Allowing admin-level control risks unpreditable behaviour. Only the receivers of notifications will be able to control them.
Template
-
[Title of 1st principle]
[Short description of our intentions with this principle]
Examples
- [Examples of how we’ve put this principle into practice]
-
[Title of 2nd principle]
[Short description of our intentions with this principle]
Examples
- [Examples of how we’ve put this principle into practice]
-
[Title of 3rd principle]
[Short description of our intentions with this principle]
Examples
- [Examples of how we’ve put this principle into practice]
FAQs
-
What if this is a new product or team?
Talk to people already on the ground, and/or or those who asked for the team to be formed. Clarify their intentions and expectations, observe and document patterns that emerge in an effort to build up early working principles. The principles won’t be right, but that’s fine – they’ll become more informed as the team begins to learn, and will be the focal point for where those learnings are documented.