My current product team has about 40 PMs (And we are hiring!). I would not dive into what each of the team does, but maybe talk about how we went about structuring it, which may be a more transferable skill. When I first joined Meta my VP asked me if the current team structure is the right one. Naturally, I did not know the answer. Frankly, I don’t think it was the right question for me to answer at the time. Instead, I engaged with the team on setting a 3 year plan - Write down what our strategy is, at a high level, and what are the key milestones that such a strategy would hit, if successful. This happened both at the org level and for the individual teams in the org. As the team presented the strategy to the stakeholders we started seeing some gaps in our org structure and the team leads started to raise a desire to organize differently. We recently re-organized the team accordingly. Setting a direction was a critical prerequisite before talking about team alignment. As for measuring success, it goes a bit to the first question I answered - I expect each team to define their own strategy, then set the milestones of that strategy. Our discussion can then be focused on the three elements I highlighted: * Strategy: Was the team able to set a good strategy? * Execution: Is the team hitting the milestone? If not, is it because the execution is not tight, or because the milestones are not achievable and we should pivot? This is a very important distinctions that some people are missing - A team can be executing really well and proving that the strategy is the wrong strategy. Being able to prove that point and move on without wasting years of struggles is a big win! * Org health: Are we hiring well? Growing talent? Retaining talent? How is the cross functional relationships going?

Design a product for drivers driving in rush hour. I am betting every human stuck in traffic has once thought... “Dang this traffic sucks, I wish I could [insert idea].” The best answer I’ve heard is a tablet-sized visual, that is connected to the internet with key apps such as email, song playlist, podcasts, call functionality; along with the capability for partial self-driving in traffic. Once in rush-hour it kicks in, frees your attention to do other things, improves health of the driver by reducing both physical and psychological strain of commuting in rush hours and is highly scalable to autonomous-capable vehicles. I liked the answer because I’d buy this product 🤪 but also because the answer was (1) optimized for reducing real pain points (2) accounted for the future of driving (3) was a little wild, but not too out there. When I heard this answer I could tell the PM was both imaginative but grounded in solving real problems.

There's a lot written about basic PM competencies (https://a16z.com/2012/06/15/good-product-managerbad-product-manager/), and for any PM on my team, they should be able to do all these things you'd expect from a PM (write specs, understand the customer, communicate upwards and outwards, GSD). I'll focus my answer on a few attributes that I think are really "make-or-break" for me: * Good communication skills, both written and verbal, are an absolute must-have for any PM on my team. Whether it's through writing specs, influencing stakeholders, or pitching product ideas, PMs have to be able to communicate effectively across mediums (written, verbal), forums (large groups vs. small groups vs 1:1) and audiences (to developers, marketers, sales, executives). In particular, they need to be able to tell good stories (e.g.,, can they get their team inspired about an idea?), structure their communication effectively (e.g., can break down ambiguous problems using a framework?) and make technical concepts easy to understand for non-technical folks (e.g., can they explain how routers work to someone without a CS background?) * Great PMs "own" the problem. They're not afraid the step outside the boundaries of their function to do what it takes to get the product out the door. They rarely ever use phrases like "that's not my job" or "this was the designer/developers responsibility". Their strong sense of ownership of the problem leads them to passionately debate about the right solution, speak truth to power when necessary, but also be open to other points of view (because it's not about "them", it's about solving the problem).

Let's take a look at common milestones of a product management career, and which skills you need the most on each level. This not an exhaustive list, but you can see the trends of how the skillset evolves. Individual contributor (IC) PM: Prioritization, trade-offs, taste (sense for what makes a good user/developer/API experience), empathy for users/stakeholders/engineers/designers, knowing how to develop and test a hypothesis, grasp of success and guardrail metrics, growth mindset (ability to change one's mind when new facts become available). Senior-Principal IC PM: Everything above plus thinking in systems (ability to see how what you're building is making impact in a broader context of your product/solution/business), influencing stakeholders, thinking in bets (Annie Duke's book is a fantastic read on this), sense of product-market fit, knowing how to craft a strategy and 1-year+ roadmap, compelling written and verbal communication skills. Between the IC and Manager levels the skillset evolves from being craft-centric to a more generic one: Manager of IC PMs (e.g. Group Product Manager or Director): vision setting (ability to articulate how a product strategy ties to a set of beliefs about the world/future), clarity (ability to absorb complexity and convey it in abstractions that are easily understood), efficiency in managing dependencies across your group and others, ability to inspire others, ability to identify talent and strengths in others, creating space for others Manager of Managers (e.g. Head of Product): Everything above plus sourcing context from other parts of organization to keep your team aware, ensuring team alignment and optimization for global goals vs local optimas, managing team headcount growth (e.g. advocating for when the team nees more people), public speaking skills to represent your team/company (you may develop public skills earlier in your career, but at this point you it's a must have), identifying good opportunities the team is not working on helping with exploring them, M&A/ability to integrate an acquired team. Manager of Managers of Managers (e.g. CPO): Everything above plus crafting internal and external narratives telling the story of what the product(s) and product org stands for, "translation" and mediation between executives and product org, advocacy up and down, dirving cohesion in quality of hiring, defining and maintaining principles and standards of product craft/PM levels/promotions, keen market awareness, sense of global product opportunities and innovation, exceptional listening skills and ability to quickly get to the core of any problem. 

I have a very simple framework for building 0-1 product - IVC framework 1. Identify: * The first step in developing any product or feature is to identify the user's needs. Hence, your goal should be to talk to as many users as you possibly can to understand what they say, do, think, and feel. This also helps you learn who you are solving for and who you are not solving for and create a problem statement 2. Validate * Building Conviction by testing Discovery, MVP, market analysis, possible conversion. During this time also you should be talking to customers to validate the problem and solution 3. Create: * Create the right team to build the product and also a plan on how you will bring the product to market.

Perhaps a contrarian take, but technical skills aren't the most critical for the majority of PM roles out there, except for deeply technical products or platform positions. For the general PM role, it's much more important to demonstrate your ability to delve into customer problems, set strategy, execute, and drive impact that aligns with your organization's mission and vision. Technical skills matter, but they are secondary. They usually revolve around your ability to work with engineering counterparts and understand enough technical concepts to make trade-offs, and to work with data and perform analysis for decision-making. In my experience, both of these skills are often inquired about directly.

I’ve held roles as both platform and non-platform product managers and I’d say being a platform product manager is definitely the most challenging but rewarding. The most challenging part is your solutions are more abstract and less obvious. Instead of building solutions directly for customers, you’re buildings tools for customers to build the solutions themselves. Does your head hurt yet? Let me give an example. Let’s say you’re trying to let customers customize the way their HubSpot UI looks. While you could try to build all the customization requests you get, no two customers want the same thing and it’d be impossible for our product teams to keep up with that demand. Instead, you build tools for external developers and admin users to configure the UI in the way they need. But how do you figure out which tools? Here is the usual process for regular product management: 1. Collect customer use cases 2. Identify a pattern 3. Build a solution that solves for the majority of use cases. Here is the process for platform product management with an extra step: 1. Collect customer use cases 2. Identify a pattern 3. Identify a pattern across solutions 4. Build a solution that solves for the majority of use cases. Still confused? Let me make the customization example even more specific. Let’s say you notice that a lot of customers want to display their HubSpot data in a table format on the CRM record page. Taking a non-platform approach, you’d build out every single table request that customers make. But this isn’t scalable. Instead, you build a configurable table component that customers can populate with their own data and then display. Believe me, I struggled for a long time with this adjustment in thinking but I promise if you choose to pursue it, you’ll love the wider impact that you’re able to have on customers!

One way I like to prioritize problems is based on the level of risk these will pose to the final solution. Which are the riskiest assumptions or riskiest bets that will affect the success of your product? (Risk can be defined crudely in terms of Low, Medium, High or in some cases you might have a model with some sensitivity analysis built in). Regardless, if you can quantify the risk (and thus impact) of the problem to the final solution, you have a clear blueprint of where to begin. A related method is to consider one-way vs two-way decisions. One way decisions are challenging or impossible to reverse - these have multiple downstream effects on the solution. Two way decisions can be reversed easily or adjusted over time once you have more data. I prefer to focus my time and energy on one way decisions first, as these will build the pillars of the product. If there is considerable time or effort spent by your team on a two way decision, you can make the argument to come back to this once you have more information or once all the one way decisions have been made.

The great thing about being the first hire is something that is also great about Product Management: there is room for interpretation. My philosophy has always been more heavily focused on understanding how things operate current state, finding out pain points as well as the more successful parts of a product, and leaning on those insights to form your next steps. In certain scenarios, what a team may need is for someone to roll up their sleeves and do the work to keep the lights on for a product. It may be months before you can get the product to a comfortable enough place to think about weeks, months, or quarters ahead; however, that time allows you to gain knowledge of the product itself. In other scenarios, a product may be operating just fine, and your task will be to understand where it can go next. Your time will be spent with customers, stakeholders, engineering and others to understand the areas of opportunity that exist. You don't always need to reinvent the wheel or start from zero just because there was not a product team in place.

Service Level Agreements (SLA) are driven by three factors: (1) industry standard expectations by customers, (2) differentiating your product when marketing, (3) direct correlation with improving KPIs. For checkout, you'll have uptime as an industry standard, but it's insufficient because subsystems of a checkout can malfunction without the checkout process outright failling. You could consider latency or throughput as market differentiators and would need instrumentation on APIs and client response. With payment failures or shipping calculation failures, you would directly impact conversion rates and trust erosion (hurting repeat buying), which are likely KPIs you care about. So your SLAs need to be a combination of measures that account for all of the above, and your engineering counterparts have to see the evidence that these matter in conjunction. Of the three types, the one that's most difficult to compare objectively is the third. In your question, you mention 1.5% error rates. You could go on a hunt to find evidence that convinces your engineering counterparts that these are elevated vs. competition, or that they're hurting the business. What's more likely to succeed is running A/B tests that attempt to improve error rates and demonstrating a direct correlation with improving a KPI you care about. That's a more timeboxed exercise, and with evidence, you can change hearts and minds. That's what can lead to more rigorous setting of SLAs and investment in rituals to uphold them.