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.

At Asana, we don't use leveled job titles to indicate seniority (e.g. Product Manager III or Senior Director of Marketing), but that doesn't mean that we don't have management structures in place. Instead, we use Success Guides for every team that help employees understand what success looks like for each role level at Asana. Another way we demonstrate ownership and growth in role is Areas of Responsibility, key areas of the business that have one designated owner who is responsible. AoRs act as a directory so employees easily can understand who does what, and they offer employees additional ways to stretch and grow outside of a traditional role structure. * As a more junior PM you are working on a well-defined initiative driving the backlog of a single program team or large workstream within a program team. You contribute to the strategy for a program, while the high level elements are largely defined already. You drive work with end-to-end responsibility around execution in a problem space that is fairly well defined. At this stage you are open and curious - your growth mindset is a career accelerant. * As a more senior PM you have a lot of autonomy in running a program team or large workstream within a program team, and are thinking boundarylessly outside your program to drive a seamless customer experience. You may be contributing to multiple backlogs and your work likely touches experiences that are owned by others. You are expected to set the strategy for your program or workstream based on the broader pillar strategy. This strategy must help Asana win. The work that you tackle is difficult, ambitious, ambiguous, and does not have a clear solution from the outset. You coach other PMs informally, and may seek out a more formal mentorship opportunity. Once someone is demonstrating all the competencies at their current level, we then start giving them extra responsibilities. It is only after demonstrating those new competencies consistently do we decide they are ready to be promoted.

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

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.

Let’s say that a product team and an executive team are aligned on the goal of improving customer satisfaction with the product (measured by a CSAT survey). The product team will then do research and perform experiments to validate the best way to impact customer satisfaction. Including executives in the research process via stakeholder interviews is a great way to get input early - executives are viewing things from a much different perspective than team ICs and often have great ideas. When the team prioritizes opportunities to pursue, the framework they use for prioritization can also be used to convey their point of view on the best way to impact customer satisfaction. If an exec suggests making an adjustment to the roadmap during the team’s roadmap review, seek to understand why and dig into their thought process. Then, seek the truth. Is there a quick way to validate or invalidate the feedback? What does the objective evidence point towards as the best opportunity to impact the goals? For more on this topic, I recommend “Cracking the PM Career” by Jackie Bavaro which has a chapter on working with executives.

Not sure I would call them hacks, but I have various things I do to manage both my workload, product execution and overall team management. 1. ToDo List Goes without saying. Be organized and find a system that works for you. Pen and paper? Go for it. Trello board? Do it. Adoption Notion? Fire away. For me, it's been about finding what system works for me and being relentless with it. My memory is generally solid, but our roles as PMs mean we shift a lot ,and keeping track of things is the only way to be successful. You don't want to be known as the PM that people have to remind about asks over and over again. 2. Manage Your Calendar with Precision I manage my calendar carefully. I block the time that I need for things like responding to interruptions and checking in with various projects each day/week. Unless it's critical, I won't move those slots and that allows me to stay organized and on top of things. 3. Kanban for the Win I have been using a Kanban-style prioritization process for over a decade. Allows me to easily see what's in flight, what I need to keep an eye on, and at any given time, what is top of the pile to focus on. Lots of great tools for this, like Trello. I try and keep it simple with a backlog of items, what's in flight, and then what's done. 4. Automate to Success So many of our daily tools have automation capabilities that we can leverage to help with the simple things. The more "little things" I can take off my plate the better off I am to focus on the value-added things in my workload. Don't fall into the trap of "it's just easier for me to do it this time". If there is a way to invest a small amount of time to automate repetitive tasks or items.....do it.

Honestly, the first product manager for a company is probably not ready to establish a prioritization framework. The first PM probably needs to focus on customer discovery, market discovery, MVP intuition, and experimentation. Until you have established product-market fit with enthusiastic customer demand, rigorous prioritization is probably bikeshedding. Once you have that fit, that's when you'll start to get inbound requests/ideas/complaints from current customers, potential customers, new market segments you hadn't considered, and sales teams eager to displace competition. Then you can start thinking about a model to trade off product vision, addressable market expansion, competitive threats, technical debt, quality & reliability, scaling bottlenecks, and so on. The question you'll ask is: What can the team work on today that maximizes short term opportunity without hobbling long term viability? Product priorities more often resemble a Bayesian decision network than a flow chart.

Technical questions are usually asked in a few contexts within a PM Interview. * Understanding a PM's experience working with engineers: These questions are usually asked in rounds led by engineering stakeholders. A typical question concerns making a hard prioritization decision due to a technical constraint. A PM is expected to know enough technical details to understand the various choices, their pros and cons, and make prioritization decisions accordingly. * Data Analysis and SQL: Most PMs do some level of data analysis themselves. Especially for early startups or lean teams where there is either no or insufficient data support, PMs are expected to know the basics of SQL, understand and prioritize where they need instrumentation, and even create some reporting/dashboarding for themselves and the company. For such a role, it's quite common to have a round on data analysis and sometimes even SQL. * Platform, Infra PM roles: If you are applying for a role that is platform or infrastructure-specific, it's expected for PMs to have a degree of understanding of the same. Technical depth also depends on the role (early or mid-career). For eg: Dev API PMs, Authentication PMs etc.

From metrics perspective, it's no different from standard product metrics. I've seen many different metrics frameworks being used, all of which essentially boil down to these 4 metric categories: 1. Operational metrics: Is the product functioning as expected? Success rates, Latency etc. 2. Usage metrics: Is the product being used? DAU/MAU, Frequency of use, customer retention/churn, Requests/sec, data volume etc. 3. Satisfaction metrics: Are customers satisfied? In-product feedback (thumbs-up, thumbs-down), NPS scores via surveys etc. 4. Impact metrics: How is the product helping customers achieve business impact? This is subjective and need to be defined per product and is also typically based on customer scenarios.

Great question! The move from Senior PM to Director level and above is a challenging one. In general, the change really involves the transition from product management to product leadership. You are typically going from managing one team at a high level with one roadmap and no direct reports to a role managing multiple teams at a high level with multiple roadmaps and direct reports AND driving an effective vision & strategy for your portfolio that brings those elements together AND provide tools and conditions for the whole org to get better at being PMs. Whew! Given the changes in responsibilities, you’re likely going to have to evolve into performing at the Director level so you can set your” opportunity table” for a Director opportunity. Given where the Senior PM level usually sits, here are probably the kinds of skills and experiences you’ll need to try to acquire: 1. Learn how to manage and mentor people. Does your company hire interns? Manage one or more of them! Does your company hire new people that need mentors? Become a mentor! Manage people volunteering somewhere! There’s lots of ways to get skills and experience here, great books too (Leaders Eat Last by Simon Sinek I highly recommend.) But in general the best teacher for managing people is experience. 2. Learn how to build product strategies at the portfolio level. If you’ve gotten to the Senior PM level, you probably know how to develop a strategy for your product or feature. But doing this as a portfolio level is different. It requires thinking longer term about multiple teams with multiple strategies & roadmaps. The best way to learn this skill is to take on the responsibility of doing this or sharing it with your boss or higher-ups. This is a stretch to do in the beginning, but the more you do it the better you get at it. Some good practice is also crafting strategies for products you like or companies you admire. See how many of them come true and how right or wrong you were. Learn, rinse and repeat. I also recommend Good Strategy, Bad Strategy by Richard Rummelt. Amazing book on this topic. 3. Help your fellow PMs in the org level up via skills like org design, policy design, tooling upgrades, etc. Basically practice the art of leveling up a team by creating an environment for PMs to level up and do great work. Think about your own experience doing your best work. What kinds of tools, policies and cultural norms were in place that really helped you level up? Now think of ways you can get from where you are today to that ideal. What tools do you need? What policies need to change? How does the culture need to change? From here, learn how to drive the highest priority items. You don’t need to be a Director for this, you can pursue it by speaking up in feedback forums on these topics, work with your peers or managers to make things happen, etc. If someone was taking initiative here, you can bet managers will be considering them for leadership spots. That’s the high level summary! The opportunity actually presenting itself requires being at a company where there is a need for someone at that level, which requires a bit of luck and timing. So all places aren’t going to be best fits for you, and you should assess that on your own as well. As for types of tracks, PM leadership skills are pretty transferrable. Director, Senior Director and VP are more traditional paths. But I’ve seen old bosses and colleagues go lots of different ways. Something I hear a lot is that the PM role prepares you for being a start-up CEO. Have certainly seen that happen! An old boss is CEO now. But I’ve also seen lots of people end up in Marketing, Design, Engineering, Strategy…there’s no one set path!