Move fast and drive impact. The power of Product Principles.

TL;DR — Product Principles — your default behaviour when faced with a decision — can help fuel faster, better, more aligned trade-offs. Here's how.

Product Management's fundamental role is to drive results. Results aligned with the company's strategy. To do that, folks across the product stack — product managers, engineers, designers — make 1,000s of decisions. It's a relative trade-off game. You always have imperfect information. There are always too many ideas. Yet, you still have to act. You are attempting to make good risk-adjusted bets.

Initially, this 'trade-off' process is done solo or between a few folks. How you do it is organic. It emerges from many, many small conversations. As a company grows, you start to write things down and create structures to get things done. Maybe you hire delivery folk or a product ops manager. It helps—kind of. Process is always imperfect, and it's impossible to set up systems and processes to 'ensure' decisions align with the strategy.

Principles — your default behaviour when faced with a decision — can help fuel faster, better, more aligned trade-offs.

Here's how.

By removing the need for needless, endless debate and giving you a simple way of navigating the thousands of decisions everyone makes each day.

Principles are a click down from your company values. They should be hyper-practical. The best test is do these principles help you make a decision. If not. Discard them. They should be aligned and map to your company values and allow you to live them out across the company.

There's no universal set of principles that work for every organisation. They have to fit your culture and stage of development. Effective collaboration among the key folks—PMs, designers, and engineers—is vital to establishing principles that work for you.

Yet, while you can't 'cooker cutter' your way of operating, you can pick up a few recipes and get some inspiration.

A few ideas

Here are my favourite principles, which I co-designed with the team at Ignition, to help kick-start the conversation with your team.

• Only make new mistakes — We should not be re-learning lessons that others have already learnt. We should harness the collective knowledge that has been built up across our teams.
• Our 'coulds' are 'coulds' our 'shoulds' are 'shoulds' — We want to be absolutely clear when something is a genuine suggestion versus a directive. This help improve debate and clarity of next steps.
• Ask don't assume — If we're unsure we seek clarity over making assumptions, it's as easy as asking. This avoids missing things and miscommunications.
• Public discussions over private DMs — We discuss our work in the open by default. We don't know what we don't know so this helps bring people together and make better trade-offs. It also makes it easier to loop folks in and find discussions later.
• Commonsense over rules — If in doubt we do what makes sense even if it's goes against a rule. Sometimes rules haven't considered a situation we face. This means we're not held back and can be pragmatic.
• Better not bitter — We commit to calling out issues. Yet, when we do we seek to improve how we operate not whinge about the problems.
• Getting it right over being right — There's no monopoly on good ideas. We are open minded about how to approach something. We don't seek to 'win' a conversation, rather seek perspective and adapt our plans based on the best information and insights we have.
• Pick up the sock —?Context switching is real. We do small bits of clean-up work in areas we're working on whilst we have focus. We do this thoughtfully and ensure it's not an excuse for scope creep.
• Progress over consensus — We need to bias to frequently shipping small improvements that are slightly better than what was there before. Trying to accommodate everyone's input and wants at once is a recipe for moving slowly. Getting started is vital. It's also humble. We know the best way to making a great product is collecting real data from real customers. We don't let ourselves be bogged down in grand plans at the expense of making a first step, learning, then expanding.
• Hero the customers, not a customer — It's better to do something that makes 1000 customers 1% happier than is it to do something that makes 1 customer 100% happier. Sometimes this means making hard trade-offs and disappointing individual customers.

Getting started

Here's a way to get started with your team today.

Grab your team or a few key folks — ideally less than 7 (much bigger, and it's hard to have a good convo.). Block out 2 hours. I've found that Friday PM works well over a beverage of choice.

Here's how I'd spend the time:

• Jot down ideas (~20 mins) — have everyone write down as many principles as they can separately. More is better at this step.
• Drive common understanding (~20 mins) — have someone read out each principle. The goal here is to have the whole group understand what someone meant. No voting or judgement yet. Just understanding.
• Group principles in common themes (~10 mins) — have someone wash through the ideas and group common ones. Star contradictory principles.
• Discuss (~30 mins) — Discuss where there are the biggest divergences. Have both sides share their take and what it practically means. Pick a recent project to help make it real.
• Vote on most impactful (~20 mins) — Have everyone vote on their Top 5 principles. Pick a voting method that works for your team. You're shooting for 5-10 that you can adopt. Less is more when starting out.
• Wrap (~10 mins). For the next steps, have everyone take the weekend to mull over and pick up again in a day or two while it's still fresh. Schedule a short session to see if views have changed or solidified. Pick a team and pilot them with some upcoming work. Schedule a review in a fortnight. Get feedback, rinse, and repeat.

Final thoughts

Personally, I've struggled to get Principles to stick or be real enough to drive action. It's too easy for everyone to either a) just want to do product their way or b) not see how principles drive actions and want to debate every separate product decision on its merits.

Both don't seem ideal to me. The less time you can spend debating and the more time building and testing aligned around a common understanding of the world, the better. Well worth keeping at even if it doesn't stick straight away.

I'm interested in how other leaders have tackled this with their teams. Do you think it's nonsense? Has it worked? What's your approach?

Feedback and comments are welcome.

?