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?

This is a two-part question. Let me first articulate how I like coming up with ideas for new opportunities, followed by how I like to make decisions about what to build. Hopefully, you don’t mind that I’m thinking about “opportunities” because it might not always be a feature that’s the right solution. I should start by saying that there isn’t one right approach to coming up with ideas. In my experience, I’ve had success ensuring that there are: 1. Insights from the four lenses: Customer, Business, Market, Technology 2. Effective methods to facilitate ideation At the core, you have to have a deep understanding of the underlying user pain point you’re trying to solve through a thorough investigation of the Customer by talking to customers and product usage. You might actually learn very quickly that the user problem is around discoverability or activation, not necessarily a feature gap. Ideally, the customer impact is so deep that it translates effectively into Business impact. The Market context is critical to help understand how your user will experience the product within the broader competitive landscape and the direction an industry is headed. Finally, the Technology lens offers insight into what capabilities could be used as part of a solution. Preferably, these four lenses come together through cross-functional ideation that has the right participants (e.g. PM, UX, Eng, and even folks go-to-market teams). In a hybrid world where we’re working across time zones, I’ve enjoyed having the opportunity to ideate together synchronously and asynchronously. In terms of decision-making, the ideation process should lend itself to initial layers of prioritization. I won’t go into prioritization frameworks here, but there are many out there. They do tend to distill back to impact and effort and sequencing. At HubSpot, depending on the type of decision we are trying to make, we may use a “driver, approver, contributor, informed” DACI model used by other companies we admire like Atlassian.

0 -1 product development refers to building a new product or service line from scratch (0) to bringing its first iteration into the hands of customers and users (1) The first step to develop a 0-1 product is to deeply understand the market need. I look at this from the buyer perspective, the end user perspective, and the competitive landscape perspective. Unless you understand, what's needed, what exists, what's missing, and what will differentiate your solution and validate your need to exist, you cannot begin the next phase, which is product definition. 

Given that it’s such a nascent function, I think there’s a lot of flexibility – I see that as a good thing! But I know the flexibility can also be daunting, so here’s how I talk about it with my team. Once you’ve been a Product Operations Manager, I think there are four primary paths: 1) Stay in Product Operations – “level up” within Product Operations and find a way to increase the scope or complexity of what you’re working on. At Oscar we have 6 levels for Product Ops, from Associate to Director and we promoted someone this past performance cycle! If your company has only one Product Ops role or title, make the business case for expanding your scope and a title change. Or look externally – many companies are building Product Ops and prior experience can be a huge asset. 2) Transition into Product Management – a benefit of working closely with Product Managers is that you get exposure to what they work on day-to-day. There are overlapping skill sets between Product Ops and Product Management, including translating needs into actionable requirements, strong prioritization skills and a deep understanding of the product you work with. I’ve had folks on my team successfully transition from Associate Product Operations Manager to Associate Product Manager – they enjoy that they’re working earlier in the Product Development Lifecycle. Note: I would be cautious if you are planning to use Product Operations as a stepping stone into Product Management. It can be a very different role from being a Product Manager and you may not get an opportunity to demonstrate Product Management skills in your day-to-day. For most folks on my team, they’ve had to take on side projects or volunteer for work outside of their swimlane to build those PM skills. 3) Transition into another Operations role – if the thing that gets you out of bed in the morning is improving processes or how things function, you may want to consider another Operations role after Product Ops. This could be within Product and Engineering – large Product Design teams are starting to build out Design Ops and/or User Research Ops. Engineering teams can have Engineering or Tech Ops (distinct from DevOps), to focus on optimizing the Software Development Lifecycle, improving Engineering onboarding and/or evaluating tools to increase developer productivity. You may want to get more creative and look beyond the Product and Engineering – the skill sets of organizing chaos, making playbooks, putting structure around things that are ad hoc, etc. are invaluable and very transferable. 4) Transition into Program/Project Management – I believe there is a big distinction between Product Ops and Program Management (I answered another question about the differences!), but there are overlapping skill sets as well. In both roles, you need to make sure people are delivering on their commitments. If your company does not have a specific Program or Project Management function, it’s likely that these responsibilities are bundled with another role – maybe even Product Ops! If your favorite parts of Product Ops are when you are coordinating across teams, tracking dependencies or chasing follow-ups, you might want to consider transitioning into a Program Management role. This can take the flavor of Technical Program Management (which may require specific technical skills) working with engineering teams or more general Program Management, which can span across all lines of business. If this career path is exciting to you and Program Management doesn’t exist at your company, define the opportunity and make a business case for these new responsibilities. There may be an opportunity to incubate the role within Product Ops, maybe as a component of your day-to-day. In talking to other Product Operations leaders, some have had Program Management teams organically form within Product Ops and before spinning them out into their own team.

As you progress from PM to senior PM, competencies in these 3 areas should grow: Autonomy💪🏽, Scope 🌫️ and Leadership 🙋 . There are a few clear indications that someone is ready for the senior level, like increased scope, being a reliable partner and being results driven. Here are some less obvious ones: #1 You recommend initiatives based on your strategic evaluation, instead of waiting for them to be handed to you. You are influential in your field and feel confident putting forward these initiatives. #2 You leverage relationships across the org. You can drive results from partners outside of your immediate team. You are fully entrusted to tackle complex, multi-team problems with little necessary supervision. #3 You are seen as an available and trustworthy mentor and actively seek out opportunities to help others be their best. This is my favorite by far. What are the key stages that distinguish the different levels of PMs? I think a little bit of this depends on the problem space and company. In my mind, PMs are professional collaborators, strategic assassins and bring out the best in their peers. If you can look yourself in the mirror and say you’re doing these things at scale, well, I’d say you're on the right track.

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.

Without going into specifics, the biggest challenge has been cross-organization influencing. My time at both Microsoft and Google has exposed me to lots of intra-organization projects with varying levels of buy-in from each team. The level of effort and coordination required to pull not one, but two organizations in the same direction can be enormous. As a PM - at any level - it's your role to effectively communicate why what you're trying to acheive makes sense for other teams, your company and ultimately your customers. Even if you're aligned on principles and strategies, there are dozens of other factors that you need to be able to navigate such as resourcing, ownership, tech stacks, recognition, branding, leadership opinions and timelines. 

I’ll skip the obvious things - pay well, set a vision, growing company, skill building, career pathing - and highlight some under-rated ones: * Hire well and have high talent density. Most people who choose a career in Product Management are motivated by self improvement - being around other talented PMs who they admire and who push their thinking is motivating. * Stay lean. This may seem counterintuitive - isn’t it good to have enough PMs? Honestly, no. If you hire well you want to give people room to grow and stretch. The worst thing you can do is to staff up too quickly, only to have frustrate your stars who are ready for more in a year (or worse yet, sudden shift in the business which requires you to scale back projects). Having too many PMs will also lead to more work being generated, you then need to resource. It’s far better to have PMs that have 20% too much to do than 20% too little. My rule of thumb is: everyone should be just uncomfortable enough with their scope that they drop a few things, but not so uncomfortable that they burn out. * Autonomy. People choose a career in product management because they want to make or be at the center of product decisions. Allowing them to do so is one of the most important things you can do to keep them motivated. As a people leader your jobs is to set goals, give context, guide, and identify blindspots. It’s not to operate the product for the PMs on your team. At Netflix we have a value, “Context over control” - leaders should focus first & foremost on setting context so others can make decisions vs. making decisions for them. * Actually care about them. When I think about the best managers I’ve had they have one intangible thing in common - I felt on a deep level that they actually, genuinely cared about me. This had a ripple effect on every part of my job because I felt supported, was calmer, and did better work. Caring looks like regularly thinking about the growth & success of another person without being asked to. It looks like advocating for or elevating behind the scenes, especially if they are in a disadvantaged position. It’s something that you can’t fake.

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.

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.