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?

Part of the fun of building something 0-1 is that you have a green field in front of you — you can build anything! (Or that's what we wish as PMS....) As much fun as it would be to the world is your product oyster, constraints help provide focus and a direction. I see the first step is making sure that you and stakeholders are aligned on what a goal or success looks like. And usually, that comes in the form of a metric that you're trying to move. If you work for an ecommerce company, you'll make very different decisions around what to build if your metric is increasing ASP versus unlocking a new vertical or segment. If your metric was the former, you might start doing user research on customer willingness to pay, or what they're thinking about when they're in the check-out flow. And if it's the latter, you'd probably start with user research into people who aren't yet your customers. Without that first constraint — what metric do we want to move, what does success look like — there's no way to focus your research and problem defintion phase. Once you have that north star to work toward, you can enter user research with your specific goal in mind. 

First of all, we need to address Amazon's terminology for these roles. A technical product manager at Amazon is generally referred to as a Product-Manager-Technical (PM-T). Whereas a Technical Program Manager (TPM) is a distinct role that sits at the intersection of product, engineering and program management. An Amazon TPM is a unique role that combines business ownership over delivery with high-level technical architecture. They are usually the program glue - that brings together PMTs, engineering teams and business stakeholders on all aspects of an initiative. However, note that this AMA is focused on the technical product-manager role or PM-T. So please make that translation whenever you see "TPM" in these questions.

The ideal product manager to engineer ratio can vary from company to company and even team to team, but it usually depends on the company size, product complexity, the skill level of the engineers, and the role scope of the product manager. A general rule of thumb is 1 product manager for every 5-10 engineers. * 1:5 - This is common in startups or small teams where the product manager may need to be in the details. * 1:10 - As the team and company grows, a product manager may manage larger engineering teams. Sometimes it's one large team or multiple engineering teams. Since product managers don't have time to be in the details for every project, they are expected to work at a higher level on setting product vision and direction rather than detailed product requirements. It is common for senior product managers to manage multiple teams. * 1:7 - This is the sweet spot where a product manager can still get into the details of a project while also having a lot of impact with a team of this size.

Great question. It's really hard to prioritize small, iterative product improvements against large new features/bets. In my experience you need both, as well as a few other aspects. The way we do it in my teams is to think of it as balancing investment levels between different buckets, and to dedicate capacity to each of these buckets. Otherwise it's a constant struggle. We've tried to describe it in this section of the Atlassian product discovery handbook talking about ideas, and that one about prioritization. A couple of different types of buckets: * Boulders, rocks and pebbles * Boulders: large investments with potentially big payoff but high uncertainty, too. E.g. one or multiple teams over one or multiple quarters. * Rocks: medium sized investments with fewer risks, but potential for delighting users. E.g. one team for a month. * Pebbles: Small, typically straightforward change. E.g. one person for a week. * Don't underestimate the impact of rocks and pebbles! In my experience users LOVE to see the app they use get better every time, that's a great way to create fans. * RUF: Reliability + Usability improvements + new Features. Think of the RUF framework as a pyramid: * At the base of the pyramid there's Reliability. Reliability is about building trust. Trust takes a long time to build, but can be destroyed very quickly — a single event of data loss or security breach can be a serious source of churn, let alone repeat incidents. So you need to invest in your product's reliability first and foremost. * Usability Improvements comes second: a feature is rarely “done” — it’s part of a system and that system needs constant tuning. In your roadmap, it is important to allocate budget and resources to keep investing in improving your current feature set. * At the top of the pyramid is new features, both large and small. Then you decide how you want to invest in each: E.g. for a super early stage app you might be spending all your time on boulders and rocks, and little in reliability or usability improvements. For a more mature product you might spend 50% in the reliability bucket and only 10-20% on new features. Then how you actually implement that in your team can vary. In my teams we look at it at investment over time: we might be focusing on a boulder for a quarter, then go back and tackle a few rocks and pebbles. Some of the teams have a rotation where 1 engineer is focusing on pebbles each week. etc. But the important part is to have a strategy and make it a conscious choice, vs something that you react to every time you get a new request from a customer or stakeholder.

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 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.

Of course they do! It's always a balance between those two sides. Mixing personal contributions with coaching other product managers can create tension if you’re not mindful. Setting clear boundaries around your schedule, defining what success looks like for both you and your team, and communicating these goals openly helps manage these two aspects. Things to Think About 1. Dedicated Coaching Time: I try and dedicate time each week to ensure my team is getting what they need and that I am providing them the opportunities to grow and gain exposure (to new skills, new teams, etc). If the team feels disconnected from their leadership, it's difficult to motivate them and keep them moving forward. 2. Defining Ownership: Whenever possible, I clarify what parts of the product I’m responsible for and what the team needs to own. When PMs clearly know what’s theirs to drive, it reduces the urge for me to dive in and micromanage. We play to our strengths, which allows me to contribute where I add unique value (eg: shaping high-level strategy or unblocking critical issues) while allowing each team member to do the same in their areas. 3. Regular Reflection: Every week and month, I reflect on where I’ve been spending my time. Did I neglect my direct product work because I was too hands-on with the team? Then I need to adjust next week. It's a constant balancing act. As I said, I work to carve out space, define ownership and teach PMs to solve problems independently, All of these ensure that your individual contributions and coaching efforts reinforce each other rather than work against each other. Over time, your team grows, and you free yourself to have a broader, more strategic impact.

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.

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.