Crafting a Product Philosophy
Product philosophies are valuable levers for product leaders to scale their impact and ensure that their product managers are all “pushing in the same direction.”
Yet, too often, product philosophies are given little attention. And, when product leaders do invest in product philosophies, if they invest in the wrong focus areas, the philosophy becomes uncompelling and loses its ability to align and unite.
That’s why we’ve crafted this guide to product philosophies, so that product leaders can accelerate the growth of their product teams.
First, we’ll first break down what a product philosophy is and why it matters for product organizations. We’ll then discuss the differences between strong philosophies and weak philosophies, and we’ll provide an example of a compelling product philosophy.
Afterwards, we’ll discuss how to craft a product philosophy and how to validate it with your direct report product managers. We’ll wrap up by providing a playbook for how to shift your philosophy over time as your business evolves.
So, let’s dig into what a product philosophy is and what it isn’t.
What is a product philosophy and why does it matter to product orgs?
A product philosophy is a cohesive set of principles and values that identifies the kinds of trade offs that product managers on the team should make.
To clarify, a product philosophy needs to hold a stance. We need to clearly understand “what we’re going to say no to”, not just what we’re going to say yes to.
Therefore, a product philosophy that simply says “yes” to many different priorities is not a philosophy at all, because it provides little guidance in ambiguous, unclear situations.
Here’s an example of a weak value within a product philosophy: "we will deliver value for our customers."
This statement doesn't tell you what you're not going to do, so don't use this statement as one of your key product values. When a product philosophy consists mostly of platitudes, it’s lost its value as a guide to decision making.
Product leaders should trust that their product managers are competent, and so they should stay away from making value statements like these in their product philosophies:
Be empathetic
Create business value
Eliminate friction
Listen to the data
All of these (and many more) are core competencies for any product manager to have, and therefore don’t warrant a place within your product philosophy. These core competencies should appear within your PM career ladder and job descriptions, but not within the product philosophy.
In other words, your product philosophy and your PM job descriptions play distinct, complementary roles within your organization.
Well, what does a strong product philosophy value look like? Here’s an example: “we will focus on long-term value for customers, which means investing in platform capabilities rather than chasing the next deal.”
This is a strong value because it clearly identifies tradeoffs across a variety of situations. Any time the sales organization comes to the product team with an urgent “seal the deal” feature request from a prospect, the product team should consistently turn down this request because they’ve clearly prioritized long-run platform capabilities and scalability.
When we create strong product philosophies, we enable teammates to be tightly aligned but loosely coupled. In other words, a product philosophy is effective when each product manager can make decisions independently without having to check in with multiple other people.
They can rest assured that their decision making framework is consistent with that of the rest of the product organization. That then enables the entire team to move quickly while maintaining high trust in one another.
Think of your product philosophy as the set of rules that drives your “product management operating system.” A product philosophy is a core subcomponent of a holistic product culture.
Speaking of product culture - there’s no such thing as a “universally right” or “universally wrong” set of values. The values that you should articulate in your product philosophy depend on your company’s priorities and needs.
To be clear, the strength of the value is based on how clearly it guides a tradeoff. As an example, let’s look at the reverse statement: “it’s more important to make one customer extremely happy right now than to make many customers somewhat happy later.”
This statement provides clarity for product, design, and engineering. While this value is in place, the team should consistently deprioritize scalability, abstraction, and future-proofing. Instead, they should focus on speed to market and depth of solution.
Now we know what the purpose of a product philosophy is, and what separates strong values from weak values. Let’s discuss how to craft a product philosophy that resonates with your product management team.
How to craft a product philosophy that resonates
Many times, product leaders seek to create aspirational product philosophies as an ideal end state for their team.
But, the problem with setting an aspirational product philosophy is that it doesn’t ring true. The point of a philosophy is to enable product managers to navigate through real-world situations, so an “ideal” philosophy doesn’t help because there are no “ideal” real-world situations.
It’s much more important to articulate the one that you currently have in place, because that product philosophy is real and relatable. Once you’ve articulated your current product philosophy, you can then shift it towards a product philosophy that unlocks more value.
To be clear, there is always some preexisting philosophy in place, even if you haven’t verbally defined it yet. Your product management organization’s previous decisions run on some set of values and tradeoffs, even if it’s not explicitly articulated in the form of a written philosophy.
So, how exactly do we craft a product philosophy that accurately captures the kinds of decisions that we make, so that it resonates with the product managers on your team?
First, look back at the last quarter of releases on your team. Answer the following questions:
Which goals did we prioritize?
Which goals did we deprioritize?
What underlying values tie these tradeoffs together?
Your goal is to get to 3-5 key values. Any more than that, and people won’t be able to remember the values, which then makes the product philosophy unhelpful.
Also, make sure that you rank the values by importance. Oftentimes, product managers will find themselves in ambiguous situations where the values will conflict with one another. Therefore, you need to make it clear which one to value over the other.
Here’s an example. Imagine that a product team has these two values: “good products refactor existing code to eliminate waste and create scalability” and “speed to market drives learning, and learning is what drives product/market fit.”
A product manager in this product team is trying to decide whether to refactor existing code to account for a new use case, or whether to build out their feature with fresh new code.
Refactoring the code will slow down their speed to market because they have to consolidate their features with previously implemented features. On top of that, they need to work through regression testing to make sure that their change doesn’t break functionality in production environments.
Which value is more important? It depends from company to company, but what you don’t want is for different product managers to run into this same situation and make inconsistent choices.
That’s why it’s crucial to prioritize these values. That way, each product manager arrives at the same conclusion when faced with the same situation.
Let’s run through an example product philosophy to help bring the concept to life.
An example of a compelling product philosophy
Imagine a product philosophy that holds the following three values, in rank order:
All value comes from solving the customer’s pain, not from solving engineering pains or design pains
Make one customer hugely successful rather than many customers somewhat successful
Never build without qualitative feedback loops
This set of values provides clear guidance on the kinds of decisions that product managers in this organization should make.
The first value makes it clear that the customers’ needs come first, and that we as product managers shouldn’t prioritize business metrics or tech debt over the needs of the customers.
In other words, we shouldn’t commit ourselves to blue skies ideation within this particular product organization, and instead we should index heavily on listening to what our customers are actively asking us for.
When this value is consistently shared across product managers, you reduce the likelihood that any of them will have selected a problem area that doesn’t resonate with the focus on customers.
The second value makes it clear that product managers need to dive deep with a single customer to unlock value, rather than spend significant time working with lots of customers simultaneously. That helps the team standardize their customer discovery processes and their decision making frameworks, which leads to increased velocity across the entire company.
In other words, products built by this product organization should focus on the depth of the solution, rather than the breadth of the solution. The focus is on “tightness of fit” rather than short-term revenue or broad applicability.
The third value enforces that product managers must get qualitative feedback, whether in the form of surveys, customer calls, or shadowing. In other words, product managers can’t declare success solely by looking at metrics, nor can they select which initiatives to tackle solely based off of looking at dashboards.
Product managers who work in this organization will not be able to run an A/B test without speaking with end users first. That then restricts the number of experiments that they can run, which in turn forces experiments to have thoughtful hypotheses.
The three values that make up this philosophy guide product managers through ambiguous situations, are consistent with one another, and provide a clear stance on what the product organization is willing to sacrifice.
You could easily argue the opposite for any of these three values. Again, there’s no such thing as a “universally right value” or a “universally wrong value.” Rather, the key is that each value clearly describes the tradeoff to make.
Validating the product philosophy
Once you’ve crafted the product philosophy, run it by a couple of your direct report PMs in private.
The ideal reaction that you want is “well, that’s obvious.” It means that you’ve correctly captured the current operating principles for your product team.
You don’t want this reaction: “I’ll work on implementing this” or “well, that’s new.” That means that your stated product philosophy doesn’t line up with the current unspoken philosophy.
If you’ve landed in a spot where your individual contributor product managers don’t recognize the philosophy, ask them to share a couple of examples of past tradeoffs that they made. That concrete knowledge can then help you to select values that better fit the current reality.
Once you’re all on the same page on “what’s in place today”, that’s when you can start to have larger debates on changing the product culture for the better.
Shifting the philosophy
As a product leader, remember that you can’t move the organization towards an aspirational end point unless everyone is on the same page with you on “what is our starting point.”
The goal of crystallizing the current product philosophy is to ensure that everyone’s on the same page with “where are we today.”
Once you’re aligned on the starting point, you can now work on shifting the values within the philosophy. Remember that you can’t add new values without removing an existing one, because each incremental value dilutes the effect of all of the other values in the philosophy.
When you’ve decided on which value to add and which value to eliminate, socialize your decision with direct report product managers, and align them towards your thinking. The objections that they raise will reflect the objections that the rest of the company will raise, so engage thoughtfully with each objection rather than brushing them aside.
Once you’ve all aligned on the values in the new product philosophy, pick a couple of recent product releases. Remind everyone that the previous decisions were appropriate in that past context, then discuss which decisions would be different under the new philosophy.
This exercise makes the new values much more concrete for your team, because now they can visualize what it looks like in practice.
What makes a product philosophy compelling is not just that you’ve clearly described what tradeoff to make, but also that all of the product managers in your company can clearly walk through the logic for that philosophy.
From here, you’ll now need to socialize the new product philosophy with cross-functional stakeholders, so that you secure their buy-in and support.
As an example, many product teams begin with the value “all features are proudly built in-house”, but as they reach massive scale, they shift towards “open platforms accelerate value, so bring in integration partners where you can.”
Here, you need to circle up with customer-facing people so that they know how to pitch the product. In the past, they were likely pitching it as “proudly built in-house”; if you have a future feature that crashes due to a partner’s API outage, your customer-facing team is going to drown in angry customer calls who expected all functionality to be controlled in-house.
And, you also need to circle up with information security teams, legal/compliance teams, and marketing teams so that they understand the downstream impact of leveraging more integration partners rather than hiring massive amounts of engineers in-house.
Every product organization must find philosophy/market fit to accelerate its growth and defend its market position, similar to how its products need to achieve product/market fit to win.
The key thing to remember is that your philosophy will need to change over time, so start practicing how to change values in the philosophy.
It’s an underutilized skill, but mastering it will make your company more resilient and adaptable in the long run.
Need more guidance on how to craft philosophies or how to shift values within your organization? Our coaches at Product Teacher have helped product leaders align and motivate their direct reports.
Closing thoughts
Product leaders don’t have easy jobs. They have to keep the current business running while also moving the product organization towards an ever-changing future.
Product leaders can make this job easier by crafting a product philosophy, because this product philosophy makes it easier for everyone in the product team to know what tradeoffs to make. As the product portfolio grows, it’s crucial that each individual product is built using a consistent decision making framework, or else the portfolio will no longer synergize as well.
To craft a product philosophy, focus first on solidifying the current unspoken philosophy. Then, identify which values you’d like to change, and clarify your rationale for why this change must be made. Next, work with your individual contributor PMs to practice making these new kinds of tradeoffs. Finally, work with cross-functional stakeholders to align them on this new decision making framework, and work through downstream impacts such as market positioning, operating models, objection handling, and contract clauses.
Product philosophies aren’t easy to build, and they’re even harder to change. But, by doing so, you’ll create clarity throughout your product team, your broader organization, and your customer base, and that clarity enables your team to ship winning products.
Thank you to Pauli Bielewicz, Siamak Khorrami, Goutham Budati, Markus Seebauer, Alina Ha, Juliet Chuang, and Shanthan Gangupantula for making this guide possible.
