{"id":20220,"date":"2020-05-28T10:33:00","date_gmt":"2020-05-28T09:33:00","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=20220"},"modified":"2023-11-03T00:22:38","modified_gmt":"2023-11-03T00:22:38","slug":"first-principles-of-product-management","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/first-principles-of-product-management\/","title":{"rendered":"The first principles of product management"},"content":{"rendered":"

Some of the best PMs I know make their decisions based on first principles. A first principle is a \u201cbasic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.\u201d.<\/em><\/p>\r\n

An example of one that we use for our developer platform team are that \u201call platform features should be like Lego blocks\u201d<\/em>, meaning that developers should be able to use any combination of features when building an app. Features should be interoperable, just like Legos.<\/p>\r\n

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.<\/p>\r\n

What about first principles for the craft of Product Management?<\/strong><\/p>\r\n

If first principles can help a PM align their team around what\u2019s most important in a product, I believe they can also serve PMs in thinking about the craft<\/em> of product management itself.<\/p>\r\n

That\u2019s what this post is about: what are the foundational propositions and assumptions of product management that cannot be deduced?<\/em><\/p>\r\n

Left Side, Right Side<\/h2>\r\n

The first principles of Product Management can be reduced to:<\/p>\r\n

A. Maximize impact to the mission: <\/strong>develop a product strategy that maximizes the impact to an organization\u2019s mission given a set of inputs.<\/p>\r\n

B. Accomplish everything through others: <\/strong>PMs do not directly build or operate the product, instead they enable those around them to do it better.<\/p>\r\n

\"\"<\/p>\r\n

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.<\/p>\r\n

Great product managers fuse these two principles into all their decisions and everything they do should derive from them.<\/p>\r\n

In retrospect, most of my previous posts are simply derivatives of these two principles. Making Good Decisions as a PM<\/a> is about principle A, Ruthless Prioritization<\/a> and Applying Leverage as a PM<\/a> were about principle B. MVPM<\/a> is a bit of both. I wish I had written this first, but frankly I needed to learn it. Let\u2019s dig in.<\/p>\r\n

. . .<\/p>\r\n

Principle A: Maximize impact to the mission<\/h2>\r\n

The focus of all employees in a company should be to fulfil the company\u2019s mission, whether that mission is to earn billions, create social good, or both.<\/p>\r\n

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).<\/p>\r\n

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.<\/em><\/p>\r\n

Defining the product strategy is a massive responsibility\u2026 how does a PM do it? By looking at three inputs:<\/p>\r\n

    \r\n
  1. What is the goal?<\/li>\r\n
  2. What the environment around them is signalling<\/li>\r\n
  3. What people, money, and time constraints exist<\/li>\r\n<\/ol>\r\n

    PMs use these inputs to form an opinion on the right path that will lead to fulfillment of the mission.<\/p>\r\n

    \"\"\"\"<\/a><\/p>\r\n

    1. What is the goal?<\/h3>\r\n

    Everything starts with the goal. If you don\u2019t know where you\u2019re supposed to go, you shouldn\u2019t even move because you\u2019re just as likely to end up further away.<\/p>\r\n

    One of the biggest issues I see with PMs is that they don\u2019t take the time to really understand the goal. They may be able to recite the mission statement, but do they understand its foundations? I\u2019m 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\u2019s future that it is supposed to live in.<\/p>\r\n

    Great product managers incessantly ask hard questions to leadership to understand the nuances \u2014 the<\/em> first principles<\/em> \u2014 that went into defining the mission they follow. The deeper one can understand it, the more precise their path to the goal will be.<\/p>\r\n

    \"\"<\/p>\r\n

    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 \u2014 far better \u2014 find opportunities for teams to combine efforts and accelerate progress.<\/p>\r\n

    Only<\/em> once a PM is sure they know their company\u2019s goal, and the goals of other teams around them, are they ready to effectively setup their own team\u2019s goals, which must ladder up clearly to the broader mission.<\/p>\r\n

    2. What the environment is signalling<\/h3>\r\n

    Most plans start out as a straight line to the goal, but the path never ends up as one. It\u2019s impossible to see all the obstacles ahead, and sometimes the goal is so far away you can\u2019t always tell if you\u2019ve drifted off course. To hedge against this, PMs have to listen to their environment to detect, anticipate and course correct the path.<\/p>\r\n

    \"\"\"\"<\/a><\/p>\r\n

    There are two main classes of environment signals you want to seek:<\/p>\r\n

    Customer signals<\/em> are the qualitative and quantitative data sets you accumulate on how customers are using the product. This data is the \u201cping\u201d from the goal, and when you hear that ping get stronger, you know you aren\u2019t veering too far off course.<\/p>\r\n

    Market signals <\/em>are the \u201casteroid warnings\u201d 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.<\/p>\r\n

    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.<\/p>\r\n

    3. What people, money, and time constraints exist<\/h3>\r\n

    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<\/a> using from other celestial bodies like Jupiter. Similarly, product teams are constrained by the money, people, and time<\/em> they have to launch a product. On any given mission, a product team will be constrained by all three of these.<\/p>\r\n

    \"\"\"\"<\/a><\/p>\r\n

    People<\/em><\/strong> 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.<\/p>\r\n

    Just like you wouldn\u2019t 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\u2019t 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.<\/em> They need the self awareness to know when they\u2019re biting off more than they can chew. We\u2019ll cover much more on people<\/em> later in this post.<\/p>\r\n

    Money<\/em><\/strong> 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).<\/p>\r\n

    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.<\/p>\r\n

    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\u2019s important that PMs understand that capital isn\u2019t limitless. In lieu of these luxuries, PMs need to consider all the money impacts when building their strategy.<\/p>\r\n

    Time<\/em><\/strong> is the ultimate constraint because unlike the other two, once it\u2019s exhausted you cannot get more of it. Time represents reality. It\u2019s the reality that products that haven\u2019t shipped have yet to produce any value. It\u2019s the reality that competitors are taking market share everyday. It\u2019s the reality that your company will run out of money next month.<\/p>\r\n

    PMs must manage time. They must ensure that that they don\u2019t miss big windows of opportunity, make the right tradeoffs<\/a>, and utilize time<\/a> as a healthy way to foster execution on their team.<\/p>\r\n

    The right path (product strategy) is at the intersection of the inputs<\/h2>\r\n

    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.<\/p>\r\n

    \"\"\"\"<\/a><\/p>\r\n

    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\u2019s just fucking complex.<\/p>\r\n

    The other dimension that I hope comes through from this section is that PMs need incredible breadth <\/em>to effectively synthesize these inputs into strategy. Knowing enough<\/a> 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.<\/p>\r\n

    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. \u201cmarketing will figure out how to distribute it\u201d). I really think this type of thinking is counterproductive and will limit your potential. As scary as it sounds, it is<\/em> important that you try to learn everything. <\/em>Temper the fear that comes with this, with the acknowledgement that, it is impossible to know it all.<\/p>\r\n

    . . .<\/p>\r\n

    Principle B: Accomplish everything through others<\/h2>\r\n

    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?<\/p>\r\n

    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\u2019t that<\/em> serious, but you get the point). As a PM, you cannot \u2014 absolutely cannot \u2014 forget that you accomplish everything through others.<\/p>\r\n

    Sorry. You\u2019re not even on the spaceship \ud83d\ude80<\/strong><\/p>\r\n

    \"\"\"\"<\/a><\/p>\r\n

    Wait, why do so many PM articles promote that PMs should be \u201cjacks of all trades, and do whatever it takes, including coding, marketing, and designing\u201d?<\/em><\/p>\r\n

    A \u201cdoing whatever it takes\u201d mentality doesn\u2019t make you a good product manager, it makes you a good employee.<\/em> When a PM is coding, writing support documents, or designing the product, they\u2019re (presumably) doing so because it\u2019s blocking the critical path to shipping. They\u2019re acting out their values as an employee of the company, not as a PM.<\/p>\r\n

    Everyone \u2014 not just PMs - should aspire to have this mentality. If an engineer happens to also be good at marketing and that\u2019s what\u2019s blocking the team, they should jump in and help. But that doesn\u2019t make them a better engineer. <\/em>The reason PMs often find themselves building-a-bunch-of-stuff is because, as the only member of a team who\u2019s not supposed to build, it\u2019s rational that they should be the first to volunteer<\/a> when things fall behind, but that\u2019s very different than saying it\u2019s part of their job as a PM.<\/p>\r\n

    Accomplishing everything through others is an irreducible first principle of product management, so to explore it deeper, we\u2019re going to completely change the analogy.<\/p>\r\n

    Product Managers are like coaches of a sports team<\/h2>\r\n

    \"\"<\/p>\r\n

    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\u2019s why the parallels are so strong\u2026<\/p>\r\n

    Coaches don\u2019t play<\/h3>\r\n

    A coach doesn\u2019t 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\u2019t win, the coach is fired, not the players.<\/p>\r\n

    A PM doesn\u2019t build, market, or support anything. We are hired to support a team in achieving our company\u2019s 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\u2019t build something great, the product manager should be fired, not the team.<\/p>\r\n

    A coach\u2019s style is dependent on the relative skill of the coach and the players<\/h3>\r\n

    When I first wrote that PMs are like sports coaches, what did you visualize?<\/p>\r\n

    \"\"<\/p>\r\n

    Not all coaching relationships are equal<\/p>\r\n

    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?<\/p>\r\n

    For example, if you\u2019re 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\u2019t \u2014 you don\u2019t have the experience to back it up. But that doesn\u2019t mean you can\u2019t be useful.<\/p>\r\n

    \r\n

    \"PMs need strong self awareness to recognize when to lead, partner, or support their team.\"<\/p>\r\n<\/span><\/blockquote>\r\n

    \"\"\"\"<\/a><\/p>\r\n

    In the framework above, \u201cskill\u201d is shorthand for the sum of the abilities, experience, accomplishments, and work ethic of the people. Here\u2019s how I\u2019ve applied it in my career:<\/p>\r\n

    When I\u2019m 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\u2019ve shipped projects and they haven\u2019t.<\/p>\r\n

    When I\u2019m 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.<\/p>\r\n

    Finally, when I\u2019m working with a team that\u2019s 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\u2019s low leverage? I\u2019ll 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<\/em> first principles and strategy. Then, I\u2019ll synthesize all this information into a document and align with them to ensure it represents their vision. At that point, I\u2019m just as free to align the company with this strategy as if I had developed it myself. I can still do my job.<\/p>\r\n

    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.<\/p>\r\n

    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.<\/span><\/p>\r\n

    When the team wins, the players are celebrated, not the coach<\/h2>\r\n

    \"\"<\/p>\r\n

    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 \u2014 don\u2019t steal it.<\/p>\r\n

    Coaches need to know what every player does to be effective<\/h3>\r\n

    \"\"\"\"<\/a><\/p>\r\n

    No one can coach a team if they don\u2019t even know how the game is played. You need to have empathy and respect for all the work individuals on your team undertake.<\/p>\r\n

    This is more useful than simply having a deeper understanding of what\u2019s easy versus hard to build. It\u2019s also about understanding what is fun and intellectually stimulating <\/em>work vs. mundane and repetitive work. No team is inspired by doing the same type of work they\u2019ve done before. That\u2019s when work becomes about a paycheque, and subsequently when the work itself is less creative and inspired.<\/p>\r\n

    For a PM, respecting this encourages you to create the project conditions that enable people on the team to grow and<\/em> accomplish the mission for the company. When you create these conditions, the outcome is deep ownership and emotional investment from everyone.<\/p>\r\n

    \r\n

    \"Project conditions that enable people on the team to grow and<\/em> accomplish the mission for the company creates outcomes is deep in ownership and emotional investment from everyone.\"<\/p>\r\n<\/span><\/blockquote>\r\n

    When a captain emerges, coaches step back and let them lead<\/h3>\r\n

    \"\"It\u2019s clear that Lebron James is the captain. His team listens to him\u2026 maybe not Wade :)<\/p>\r\n

    As a team member, it\u2019s one thing to hear about how you\u2019re not executing from your coach, it\u2019s 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.<\/p>\r\n

    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.<\/p>\r\n

    Typically, in this dynamic PMs will continue to lead strategy, while the captain drives execution, however PMs should also be open to \u201cgiving up\u201d 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).<\/p>\r\n

    Coaches ensure the team is training and in a peak state of performance<\/h3>\r\n

    Coaches don\u2019t spend all their time looking at video replays and strategizing with the team, they\u2019re also ensuring the team practices regularly so they can perform at their peak.<\/p>\r\n

    The parallel for product teams are product development processes. Whether you\u2019re hardcore agile\/scrum, \u201cprocess-less\u201d (note: a process exists whether you choose to acknowledge it or not), or something in between \u2014 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.<\/p>\r\n

    Coaches nurture the energy levels and mental state of the team<\/h3>\r\n

    This is an uncomfortable ownership concept for many PMs, but whenever I see a team that doesn\u2019t seem excited about the work or looks burnt out, I\u2019ll put pressure on the PM to foster a healthier dynamic.<\/p>\r\n

    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 <\/em>\u2014 the first principles of their<\/em> being \u2014 and then build meaning and purpose from work on top of those principles.<\/p>\r\n

    This concept can come off as self aggrandizing (get out of my head PM!!!<\/em>), 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\u2019ing and leadership in general.<\/p>\r\n

    . . .<\/p>\r\n

    \r\n

    \"The thing about first principles is that nothing else matters in the long run.\"<\/p>\r\n<\/span><\/blockquote>\r\n

    Exploring the first principles of Product Management reveal that it demands equal effort from the left and right brains. It\u2019s equal parts art and science. It\u2019s equal parts hyper-rational and hyper-emotional.<\/p>\r\n

    <\/a><\/p>\r\n

    It\u2019s the polarity of these two ways of thinking that make the craft of product management complex, exciting and frustrating all at once.<\/p>\r\n

    Success for PMs means respecting both of these principles equally. Create a product strategy that maximizes impact to the mission, and have a coach\u2019s mentality to accomplish that mission though the people around you.<\/p>\r\n\r\n

    . . .<\/p>\r\n\r\n\r\n\r\n

    Originally posted on Brandon's<\/a> Medium.<\/p>\r\n","protected":false},"excerpt":{"rendered":"

    Some of the best PMs I know make their decisions based on first principles. A first principle is a \u201cbasic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.\u201d. An example of one that we use for our developer platform team are that \u201call platform features should be like Lego blocks\u201d, meaning that developers should… Read More ￫<\/a><\/p>\n","protected":false},"author":341,"featured_media":20286,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[493],"tags":[],"class_list":["post-20220","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-design"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n