Some of the best PMs I know make their decisions based on first principles. A first principle is a “basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.”.
An example of one that we use for our developer platform team are that “all platform features should be like Lego blocks”, meaning that developers should be able to use any combination of features when building an app. Features should be interoperable, just like Legos.
First principle thinking helps PMs because as companies scale, communicating the rationale behind historical, current, and future decisions can be simplified in a way that their team and stakeholders can rally around. This enables people around the PM to move quickly in the same direction, decouple, and make smart trade offs without their presence.
What about first principles for the craft of Product Management?
If first principles can help a PM align their team around what’s most important in a product, I believe they can also serve PMs in thinking about the craft of product management itself.
That’s what this post is about: what are the foundational propositions and assumptions of product management that cannot be deduced?
Left Side, Right Side
The first principles of Product Management can be reduced to:
A. Maximize impact to the mission: develop a product strategy that maximizes the impact to an organization’s mission given a set of inputs.
B. Accomplish everything through others: PMs do not directly build or operate the product, instead they enable those around them to do it better.
These two principles represent the left and right sides of your brain. The left is defined by logic, research, and rigour. The right is defined by creativity, intuition, and empathy.
Great product managers fuse these two principles into all their decisions and everything they do should derive from them.
In retrospect, most of my previous posts are simply derivatives of these two principles. Making Good Decisions as a PM is about principle A, Ruthless Prioritization and Applying Leverage as a PM were about principle B. MVPM is a bit of both. I wish I had written this first, but frankly I needed to learn it. Let’s dig in.
. . .
Principle A: Maximize impact to the mission
The focus of all employees in a company should be to fulfil the company’s mission, whether that mission is to earn billions, create social good, or both.
To this end, the vast majority of people in a company are directly working towards providing a product/service to customers: they are building the product (engineers and designers), taking it to market (marketing and sales), or helping existing customers (support).
Product management does nothing to directly build or operate the product for customers. Instead, its core responsibility is to look ahead and inform the builders/operators of the product what the right path is to achieve the goal. That path is also called the product strategy, and the best ones are those that maximize impact to the mission.
Defining the product strategy is a massive responsibility… how does a PM do it? By looking at three inputs:
- What is the goal?
- What the environment around them is signalling
- What people, money, and time constraints exist
PMs use these inputs to form an opinion on the right path that will lead to fulfillment of the mission.
1. What is the goal?
Everything starts with the goal. If you don’t know where you’re supposed to go, you shouldn’t even move because you’re just as likely to end up further away.
One of the biggest issues I see with PMs is that they don’t take the time to really understand the goal. They may be able to recite the mission statement, but do they understand its foundations? I’m talking about the customer assumptions that led to it, the moral/ethical/design boundaries the company intends to stay within to achieve it, and the vision of the world’s future that it is supposed to live in.
Great product managers incessantly ask hard questions to leadership to understand the nuances — the first principles — that went into defining the mission they follow. The deeper one can understand it, the more precise their path to the goal will be.
PMs also need to know how other teams are also contributing to the effort. Especially in large companies, aligning across all teams ensures that collisions are avoided and — far better — find opportunities for teams to combine efforts and accelerate progress.
Only once a PM is sure they know their company’s goal, and the goals of other teams around them, are they ready to effectively setup their own team’s goals, which must ladder up clearly to the broader mission.
2. What the environment is signalling
Most plans start out as a straight line to the goal, but the path never ends up as one. It’s impossible to see all the obstacles ahead, and sometimes the goal is so far away you can’t always tell if you’ve drifted off course. To hedge against this, PMs have to listen to their environment to detect, anticipate and course correct the path.
There are two main classes of environment signals you want to seek:
Customer signals are the qualitative and quantitative data sets you accumulate on how customers are using the product. This data is the “ping” from the goal, and when you hear that ping get stronger, you know you aren’t veering too far off course.
Market signals are the “asteroid warnings” that represent shifts in the world that will affect your path. They are the changes in the competitive, political, and socioeconomic landscapes that affect your company and customers.
Constantly listening to the world outside your company walls is a critical input to great product management. And what you hear from customers is the ultimate validation of your achievement of the goal.
3. What people, money, and time constraints exist
How far a rocket ship can go is constrained by the fuel it holds, the quality of its crew, and its time-constrained ability to leverage gravitational boosts using from other celestial bodies like Jupiter. Similarly, product teams are constrained by the money, people, and time they have to launch a product. On any given mission, a product team will be constrained by all three of these.
People on a product team often represent the biggest constraint. Too often, that constraint is only thought of as the number of people working on a product (which it can be), but vastly more important are actual skill and experience levels of the people on the team.
Just like you wouldn’t put the rookie class of NASA on its first mission to Mars, there are product scopes that are beyond the ability of some teams. This isn’t their fault, and says nothing of their eventual abilities, but it is something that PMs critically need to understand when figuring out the path forward. To be clear, this applies to the PMs themselves, as well. They need the self awareness to know when they’re biting off more than they can chew. We’ll cover much more on people later in this post.
Money is a constraint that relates to the ability of a team to hire the right people (salaries), enable them to work (overhead like office space), operate the product (servers and support), and distribute it (marketing).
It would be silly to spend all of your money on salaries to hire the best team, but then not have an office for them to work in, or not have a single dollar to pay for marketing and thus very few customers will find the product.
Most companies have abstracted away the overhead, operating, and marketing cost complexities from PMs (so that they can focus on product and distribution), but it’s important that PMs understand that capital isn’t limitless. In lieu of these luxuries, PMs need to consider all the money impacts when building their strategy.
Time is the ultimate constraint because unlike the other two, once it’s exhausted you cannot get more of it. Time represents reality. It’s the reality that products that haven’t shipped have yet to produce any value. It’s the reality that competitors are taking market share everyday. It’s the reality that your company will run out of money next month.
PMs must manage time. They must ensure that that they don’t miss big windows of opportunity, make the right tradeoffs, and utilize time as a healthy way to foster execution on their team.
The right path (product strategy) is at the intersection of the inputs
When PMs know the goal, understand the environment, and respect the constraints, they have the necessary inputs to build a great product strategy, which sits somewhere in the intersection of those inputs.
My reductionist analogy may imply this is easy, but let me be clear that forming a good strategy is very, very difficult. In fact, despite being confident enough to write this post, I am not confident that I can always find the right strategy in practice. It’s just fucking complex.
The other dimension that I hope comes through from this section is that PMs need incredible breadth to effectively synthesize these inputs into strategy. Knowing enough about engineering, UX, data, finance, organizational design, operations, research, marketing, etc. makes your ability to synthesize these inputs more effective, and thus your strategy will have a higher likelihood of being successful.
I feel many PMs get intimidated by this reality and react by specializing in a domain and/or outsourcing the thinking from a domain to another team (e.g. “marketing will figure out how to distribute it”). I really think this type of thinking is counterproductive and will limit your potential. As scary as it sounds, it is important that you try to learn everything. Temper the fear that comes with this, with the acknowledgement that, it is impossible to know it all.
. . .
Principle B: Accomplish everything through others
In the rocket ship analogy, who did you think the PM was? Were they the person who planted the flag on planet Goal, or were they one of the astronauts on the ship?
The answer is neither. The PM was actually Mission Control back on Earth. Their job was to support the astronauts who were actually risking their lives for the mission (okay building product isn’t that serious, but you get the point). As a PM, you cannot — absolutely cannot — forget that you accomplish everything through others.
Sorry. You’re not even on the spaceship 🚀
Wait, why do so many PM articles promote that PMs should be “jacks of all trades, and do whatever it takes, including coding, marketing, and designing”?
A “doing whatever it takes” mentality doesn’t make you a good product manager, it makes you a good employee. When a PM is coding, writing support documents, or designing the product, they’re (presumably) doing so because it’s blocking the critical path to shipping. They’re acting out their values as an employee of the company, not as a PM.
Everyone — not just PMs - should aspire to have this mentality. If an engineer happens to also be good at marketing and that’s what’s blocking the team, they should jump in and help. But that doesn’t make them a better engineer. The reason PMs often find themselves building-a-bunch-of-stuff is because, as the only member of a team who’s not supposed to build, it’s rational that they should be the first to volunteer when things fall behind, but that’s very different than saying it’s part of their job as a PM.
Accomplishing everything through others is an irreducible first principle of product management, so to explore it deeper, we’re going to completely change the analogy.
Product Managers are like coaches of a sports team
There is no better analogy for how a PM should think of their role than the coach of a team sport like basketball, volleyball, football, etc. Here’s why the parallels are so strong…
Coaches don’t play
A coach doesn’t play. They are hired to support a team, and do so by helping them increase their individual and collective potentials. They are measured - by the team and owners alike - by winning. Generally, if a team doesn’t win, the coach is fired, not the players.
A PM doesn’t build, market, or support anything. We are hired to support a team in achieving our company’s goals. We do this by enabling the team to maximize their individual and collective potentials by aligning everyone on a product strategy (principle A) and fostering a healthy team dynamic. Generally, if the team doesn’t build something great, the product manager should be fired, not the team.
A coach’s style is dependent on the relative skill of the coach and the players
When I first wrote that PMs are like sports coaches, what did you visualize?
Not all coaching relationships are equal
Do you see the coach as a parent and the team as kids? Or are the players like Lebron, telling the coach what to do? How about the wrist wrapping assistant coaches?
For example, if you’re a PM straight out of college and you join a product team of seasoned engineers, why in the world would you play a leadership role? You shouldn’t — you don’t have the experience to back it up. But that doesn’t mean you can’t be useful.
"PMs need strong self awareness to recognize when to lead, partner, or support their team."
In the framework above, “skill” is shorthand for the sum of the abilities, experience, accomplishments, and work ethic of the people. Here’s how I’ve applied it in my career:
When I’m the PM on a team of fresh grads, I will take a very direct leadership approach. I will prescribe the frameworks, goals, and even how to organize the execution of the project. This makes sense, I’ve shipped projects and they haven’t.
When I’m working with a team of equal skill to myself, I will default to collaboration on all key decisions, and aspire to get buy in from everybody on the strategy and execution. To be clear, a PM should aspire to collaborate in all cases, but this relative-skill dynamic warrants it the most.
Finally, when I’m working with a team that’s more experienced and accomplished than myself, I will revert to an assistant coach or trainer mindset. I will ask, how can I be helpful? What can I take off your plate that’s low leverage? I’ll play a pure support role. For example, I will start by asking the experienced team about their vision, and then follow it up with lots of questions to get down to their first principles and strategy. Then, I’ll synthesize all this information into a document and align with them to ensure it represents their vision. At that point, I’m just as free to align the company with this strategy as if I had developed it myself. I can still do my job.
Note that in all cases, the PM is still responsible for the development of the product strategy, but how they get there can be very different.
Without a doubt, not understanding this dynamic of relative skill between the team and the PM, is the number one reason that PMs fail. They misread the situation, fall into the trap of thinking PM equals mini-CEO by default, and immediately lose trust with their team, which takes ten times as long to win back.
When the team wins, the players are celebrated, not the coach
People rarely talk about the coach when a team wins. The same should be true for product teams. If your team does incredible work, they deserve the spotlight — don’t steal it.
Coaches need to know what every player does to be effective
No one can coach a team if they don’t even know how the game is played. You need to have empathy and respect for all the work individuals on your team undertake.
This is more useful than simply having a deeper understanding of what’s easy versus hard to build. It’s also about understanding what is fun and intellectually stimulating work vs. mundane and repetitive work. No team is inspired by doing the same type of work they’ve done before. That’s when work becomes about a paycheque, and subsequently when the work itself is less creative and inspired.
For a PM, respecting this encourages you to create the project conditions that enable people on the team to grow and accomplish the mission for the company. When you create these conditions, the outcome is deep ownership and emotional investment from everyone.
"Project conditions that enable people on the team to grow and accomplish the mission for the company creates outcomes is deep in ownership and emotional investment from everyone."
When a captain emerges, coaches step back and let them lead
It’s clear that Lebron James is the captain. His team listens to him… maybe not Wade :)
As a team member, it’s one thing to hear about how you’re not executing from your coach, it’s another thing entirely to hear it from someone putting in the same work as you. As a coach, when a player on your team emerges as a leader; someone who holds the rest accountable and challenges them to be better, you have the foundations for the highest performing type of team.
In product teams, this person is typically an engineering or UX lead. When this happens, count your blessings and then work to further elevate their influence on the team. Make them a coach, too, and your co-founder.
Typically, in this dynamic PMs will continue to lead strategy, while the captain drives execution, however PMs should also be open to “giving up” strategy as well, if it keeps the captain engaged and makes them feel true ownership. This is where you need to suppress your ego. It is so rare to find people who want to be leaders, so if the captain emerges, do whatever you can to capitalize on it (but hold them accountable, too).
Coaches ensure the team is training and in a peak state of performance
Coaches don’t spend all their time looking at video replays and strategizing with the team, they’re also ensuring the team practices regularly so they can perform at their peak.
The parallel for product teams are product development processes. Whether you’re hardcore agile/scrum, “process-less” (note: a process exists whether you choose to acknowledge it or not), or something in between — the coach is responsible for ensuring the team commits to a process that enables them to do their best work. Note that the optimal process will be different for each team and coach dynamic.
Coaches nurture the energy levels and mental state of the team
This is an uncomfortable ownership concept for many PMs, but whenever I see a team that doesn’t seem excited about the work or looks burnt out, I’ll put pressure on the PM to foster a healthier dynamic.
This is difficult of course, because people are complicated. We are all motivated to do our best work by different things: some of us need encouragement, some need to be challenged, some need a friend, and some need all three at different times. PMs need to find a way to understand what makes individuals on their team tick — the first principles of their being — and then build meaning and purpose from work on top of those principles.
This concept can come off as self aggrandizing (get out of my head PM!!!), but it is the right one for a coach and PM to have. Creating an energized and committed team is fundamental to success, and achieving it repeatably is the pinnacle of good PM’ing and leadership in general.
. . .
"The thing about first principles is that nothing else matters in the long run."
Exploring the first principles of Product Management reveal that it demands equal effort from the left and right brains. It’s equal parts art and science. It’s equal parts hyper-rational and hyper-emotional.
It’s the polarity of these two ways of thinking that make the craft of product management complex, exciting and frustrating all at once.
Success for PMs means respecting both of these principles equally. Create a product strategy that maximizes impact to the mission, and have a coach’s mentality to accomplish that mission though the people around you.
. . .
Originally posted on Brandon's Medium.
