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?

As a first PM, you will need to be very judicious with how you allocate your time and resources. In fact, I think that’s true for larger companies as well. There are always going to be more ideas than resources available. As a product manager, you are responsible for translating the company’s vision into a roadmap so your first priority should be internalizing the company’s goals. Is it to drive sign-ups? Increase retention? Increase MRR? Or something else altogether? Narrowing in on that top goal helps to weed out work that may be less relevant. Once you’ve identified the top goal (there may be more than one), filter out any initiatives that do not map to this goal. The exceptions being pressing engineering initiatives (i.e. a platform upgrade, reducing technical debt etc.) or time-sensitive projects. Hopefully, you’ve been able to narrow down your list through this process of elimination. This is where a prioritization framework will come in handy. My go-to is the impact/effort matrix. It is very similar to ICE and RICE but simpler and more visual. For each initiative, assign an estimated impact to a measurable goal and a level of effort. Make sure to collaborate with your engineering and design counterparts when evaluating each initiative. This will reduce the chance of your own bias getting in the way and lead to better prioritization. For those initiatives left on the cutting room floor, think of a way you could still make some progress—is there an MVP you could run to learn something while the teams are working on the selected initiatives? There might be a low-cost way to validate assumptions via user research or data deep dive so that by the time you go through this exercise again, you are able to make a more informed decision.

I’ll try to answer this first question along with the question of - “What metrics do technical product teams look at to define success, what do you find to be the most important?“ because they are similar. KPIs or Metrics are essentially a way to measure how successful your program or product is. There are a few traits any ‘metric’ should possess - they should be explainable, able to move/influence by the team, able to test for impact, without any bias and more importantly tied to the business goal you are trying to accomplish. The metrics you’d want to define and track will likely vary based on factors such as - what type of program/product you are building (Eg: External consumer focused Vs Internal scale focused)?, what stage in the lifecycle it is in (Eg: Prototype Vs Growth Vs Mature), what matters to you within that lifecycle phase (Eg: During growth - User Acquisition Vs Revenue). Generally speaking you’d want to have a set of business (Eg: User growth, Revenue) and technical metrics (Eg: Availability, Latency) to provide a more balanced view. And don’t be afraid of (re)defining your success measures as your products/programs evolve. One of the common pitfalls I see is technical product/program managers having a myopic focus on legacy metrics that has far outlived its purpose.

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!

1. Ability to communicate well - Someone told me early in my career: The single most important PM skill he looks for when hiring a PM is communication. Communication is really a proxy for building trust, driving alignment, having healthy debates when there’s conflict and committing to a path forward. That’s all under the hood of good communication, and is instrumental in driving product teams forward. 2. Data driven mindset - relevant to qual as much as to quant. Ask yourself and teams the right questions. Become familiar with qualitative research tools, understand what your dashboards need to look like, and get your dashboards in place. Be empowered to make data-driven decisions. 3. Ruthlessly prioritize - every day you have more you want to do than you will have time to do it. That’s just the reality. Every human has 24 hours, and one can’t change that. Make sure you prioritize your team and the team's time and resources.

Success metrics and voice of the customer. Ideally, at the time of defining a product strategy, you’ve also invested time in thinking about specific Goals that are important to measure progress against it. The goals should be time bound and specific and may include product usage, customer satisfaction, and financial performance. Several product organizations (including HubSpot, Google, Spotify, Twitter, LinkedIn, and Airbnb) like using the Objectives and Key Results (OKR) framework. Metrics are important, but at the end of the day, the best true north is the voice of your customer. If your customer is happy, the rest will follow.

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.

I'm lucky in that Google has a really rigorous interview process that I benefit from. Google is also known for taking a long time during that process but I promise you that is largely because of the rigor. Post that process though what I look for are three key signals 1. Grit is my first. Big companies are notoriously slow, process heavy, and plodding. But the way I look at this is that with so much user trust, such a large business, and really a huge opportunity that we have to respect we want to get it right. I tell my team all the time that if you want to go fast go alone, but if you want to go far go together. And we've all chosen to go far so grit is critical (and sounds cooler than patience) 2. Passion. Yes this one could seem to fly in the face of the first one. But I often find that I'd rather have somebody always frustrated we can't move faster, always frustrated that we can't do better and help them mature into taking a balanced position than the other way around. Another way to say this is that I can help show somebody the upside of measuring twice and cutting once, but I've never been able to teach passion. 3. Finally EQ. Most of what PMs do depend on building trust and trust is built via relationships. Too much detail isn't likely needed here as this one is obvious but where I will go into detail is that EQ isn't the same thing as being sociable. I have excellent PMs on my team who build strong relationships that aren't loud and in your face extraverts. EQ comes in all shapes and sizes so look carefully.

I think the best way to break into the industry as a PM is to get after building tech products yourself. Personally, I left a well-paying job in the energy sector to work on a start-up with no reliable paycheck. Thinking back on that experience, it was crazy beneficial to learn how to work with designers & engineers to build a great product or feature. The act of building a product or feature is the best teacher. I’m not advocating that you should quit your job and not get paid to build stuff like I did! There was a lot that wasn’t so awesome about that. 😅 But I definitely WOULD encourage everyone here to think about how you could do that in your spare time. What problems are you passionate about solving? What kind of product or feature could help you solve that problem? How could you bring that solution to life? How can you talk to prospective customers about it? Even PM candidates that make wireframes or prototypes to show a product that solves a real problem have a leg up over most of the other candidates. I’ll take someone with drive, initiative and passion for the work 10 times out of 10.

It can be tempting when joining a new organization to find something small to ship but you should remember that shipping does not mean a "win", you want to drive a successful outcome. So instead of focusing on finding something to ship, focus on finding a way to improve an outcome. That might be making it easier for the sales team to know what just shipped, giving the support team visibility into the bugs that are being worked on by the team or some other process improvement that makes life better for your customers or your team.