The candidate must “spike” (“8/10” or higher) in all of these areas, in order of importance: 1. Critical Thinking Given how many decisions and complex problems are thrown at PMs, this the #1 most important attribute I screen for. They don’t need to be a rocket scientist (top 0.5% of population) but they should be exceptional at this (top 5%). Good looks like: * Take large ambiguous problems and break them down into smaller pieces * Uses logic to convince others * Gets to the root of the issue: Think about things from multiple angles but then focuses on what matters (this is key and hard to find). The more senior a candidate the more critical thinking/problem solving looks like: starting the why and bigger picture, being principles-based, helping others to structure their thinking (good frameworks, simplifies and structures conversations etc.). I usually test for this both in the initial phone screen and through a product thinking interviews (case questions, panels) 2. Drive PMs have a lot of responsibility, get very little direction, and get too much credit and blame, so they need to a) self start and b) be motivated to keep trying even when faced with obstacles. Good looks like: * Ownership over outcomes vs. just doing the activities? A former manager of mine once called this “an insatiable desire to ship” * Self starter - Can we throw them at a problem and trust them to figure it out without hand holding? * Vigilance - do they generally think ahead to the outcome they are trying to achieve? Do they proactively address what may get in the way? This is very hard to screen for in an interview but you can get signals from behavioral questions, their questions to you, and follow ups. 3. Bridge Building There are two parts of bridge building 1. EQ - not easily coachable 2. Communication - this includes both written and verbal communication skills and both the quality and frequency of comms. Verbal and written comms are usually coachable. It’s ok if someone isn't a perfect communicator because people improve on this over time. But it’s not ok if they don’t have sufficient EQ. Good looks like: * Self aware - seeks to know (and improve on) their own strengths and weaknesses, self reflects without defensiveness * Situationally aware - skillfully navigates people situations and figures out how to influence others towards an outcome * Concise and clear answers that are easy to follow, verbally and written. I usually test for written and verbal comms in the panel exercise and interview questions. I test for self awareness and situational awareness in behavioral interviews.

Generally, I am thinking of success in 3 dimensions: Vision, People and Execution. All three need to work well for a team to succeed over time. Early in your career Execution takes a bit of a higher focus. You can get your first 2-3 promotions by launching bigger and more complex projects. However, as you grow in your career the ability to offer broader, more ambitious vision and have others join you in the journey become more central for your success. Your already proven execution skills help in attracting people to work with you since they know you will deliver. It’s important to invest in all three dimensions throughout your career, since honing these skills takes time. When I joined Meta I was excited to find out that here we are formally aligning PMs expectations with similar axes: Impact (which includes Strategy and Execution) and Capacity Building (which includes healthy team and cross functional relationship as well as broader contributions to the organization). I believe this structured view creates the right incentive and culture.

We have a great podcast episode about this! To summarize, it’s less about explicit processes and more about tools in the toolbelt. It’s all about right tool, right job. The tools that come to mind for incorporating customer feedback are: 1. User research. This typically involves a full user research team, crafted questions and a lab that users visit to provide feedback on designs, prototypes, live product, whatever is being used for testing. But sometimes it’s something you do on your own with the help of a user researcher. 2. Surveys. This usually involves working with someone that specializes in surveys, product marketing or something you do yourself (very carefully!) to survey customers about what things they like and don’t like about new or current product features. You can also ask about how likely they are to promote the product or feature to their friends, prices they’re willing to pay for products, etc. 3. Customer Support Feedback. This is what customers tell your customer support team if you have one. A great way to collect this is to sit with your customer support team and either field calls yourself or listen in while others are fielding calls. 4. Written Feedback. Can come from a feedback widget on a website or app, app store reviews, emails to the CEO, etc. This tends to be lower fidelity but can be really useful when troubleshooting or looking for lots of feedback volume. 5. Quantitative Data. This is not something people usually think of when it comes to customer feedback! But Quantitative data is really just a data representation of customer feedback. It shows what customers are actually doing. And, when analyzed properly, can reflect what you see in the more qualitative methods above. There are more, but these tend to be the most common ones. Depending on what the need is for a product or feature you’re working on, you might want to use different tools for different purposes and project phases. For example, if you’re trying to redesign a product page for the whole website, it’s worth taking your time. It would make sense to start looking at quantitative data and written feedback early in the process. Then, once you have prototypes to test, user research can play a bigger role. But maybe you have some bigger questions to answer before then, like what kinds of elements do users want to see on these pages? Then engaging user research to help figure that out can be a big help since it’s less structured and more complex. And of course sometimes you need something fast to ship in the next few days. Written feedback, quick surveys and customer support feedback can be really helpful. Each of these tools have some bias baked in as well. For example, written feedback is more biased to more engaged, more passionate users. So it’s good to keep in mind what those biases are and figure out how best to use those tools depending. Great question!

A technical product manager at Amazon is generally referred to as a Product-Manager-Technical (PM-T). A PMT can have ownership over a product, a functional area or even a program, but their primary focus is on formulating the vision, the strategy and roadmap for that area. They are also ultimately responsible for the end metrics of adoption, quality and effectiveness of the features they deliver. They are also the primary customer champions synthesizing their current pain-points, as well as anticipating future needs. They develop concept documents (PRFAQs), Business Requirements, and Product Definitions. These are not exclusive to PMTs since Amazonian culture drives the notion of ownership, customer obsession and invention into everyone, but these are responsibilities that are more core to PM/PMTs. A Product Manager (PM) shares all of these same qualities and responsibilities with a lower bar on technical expertise which may be more suited for specific roles involving less-technical products or less-technical functional areas within a larger portfolio. 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. To address a common misperception, TPMs are not project managers, but have far more involvement in business outcome, product decisions and typically posess engineering and architcture skills that allow them to coordinate efforts across product areas. 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.

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.

There are multiple things you need to get right before you start building a product, because the most likely outcome of creating one is that it will fail. To see an example of this you can watch this talk for how we did problem and solution discovery when creating Jira Product Discovery * Validating the problem space is important. For that I think the recipe is pretty straightforward: talk to customers and prospects and let them guide you. It's quite important to go in there open minded about what you're going to learn - because there's a high chance that all the assumptions you made when going into these conversations are wrong, that people don't face the problems you thought they faced, or not with the intensity that you imagined. I'd recommend getting coaching from a user researcher on interview techniques - otherwise you can easily meet with 50 customers and learn nothing. It's one of the most important skills for PMs (and humans are naturally pretty shit at this so it REALLY takes coaching). * You want to land on problems that are felt very strongly and urgently by the people you talk to, and are pervasive. * By doing all this you'll form a view on who your target customer is - you want to keep refining this. And you'll identify potential customers you'll want to work with to shape the solution. We call them "lighthouse users" and it's who you would want to build the solution for: they feel the problem strongly, are crafty and have tried many different solutions to solve them to no avail, they're great communicators, easy to collaborate with and have urgency in solving the problem. Find them, and the rest of the journey will be much easier! Read this post to learn more about lighthouse users. * But on its own it's not enough, there are other aspects to tease out. * You want to be clear on if there is a market - check out which companies play there, try to get a feel for their revenue and growth (there's a lot you can glean about that online); if you can, try to chat with investors who gave them money; understand the maturity of this market (early adopters, early/late majority, etc.). * You want to have a thesis for how you can win - e.g. do you have a distribution advantage, access to tech that's hard to reproduce, other? Note that the best product doesn't necessarily win distribution is going to be key to answering this question. * Distribution is super important and what will make or break your product. It's a good idea to validate demand and your ability to reach potential customers. In the past I've done this by creating and advertising a landing page on a website stating the problems and asking people to join a waitlist. That's how we knew we were onto something in the early days of Jira Product Discovery - within 3 weeks we had 3000 people on the waitlist (which contained zero information about the solution). * You need to have a clear answer on "why now?" - the problem needs to be felt really strongly and urgently by customers, maybe there is new tech opening new possibilities, maybe it's the right moment for your company to invest because of strategic reasons, etc. But you need to be clear on why this needs to happen now vs next year. * If you're in a bigger company with cash at hand, assess build/buy/partner opportunities - before jumping straight to creating something a new product: is there another company you could buy instead of building, and fast track everything by a couple of years? * Even after answering all this I wouldn't jump straight into asking for engineers. I'd only do that if we're not clear the solution is feasible, e.g. if it requires new tech that we don't master. After problem discovery, don't skip solution discovery! There's a lot you can/should validate without writing code: * In the past I've shown people slides with value propositions and asked them to explain back to me how the solution would help them. There's a lot I learnt by doing that! * Create prototypes, in Figma, or live prototypes than people can play with. You can gauge the reaction of the people you give them to: if they "just" look enthusiastic about the solution you can throw it away. If they're straightaway asking you if they can please please please start using it tomorrow then you know you're onto something * Even if you ask for an engineering team: start with technical spikes and prototypes, the goal is to validate the solution solves the problem and is feasible. All of this will also help you refine your understanding of the problem space (problem <> solution work hand in hand) You can also read more about it in the Atlassian Product Discovery handbook, that we wrote to help with things like this. Check out the "Ideas" section.

In my mind, it's not an either-or. By growing existing talent, you retain organizational knowledge and build a shared culture, while bringing in external hires inject fresh perspectives and sometimes specialized skills lacking within a PM team. When I am looking at my team structure and needs, I often consider the following: Things to Consider: 1. Internal Development Programs: Promote from within by offering training, mentorship, and rotational programs that broaden your team's exposure. This approach (in my experience) strengthens loyalty, develops institutional knowledge, and keeps your product strategy consistent. 2. Hire Externally: Often times PM teams get into stuck patterns and fresh perspectives are invaluable for a team's growth. When I need new capabilities, like a strong data analytics background, or experience in a specific market segment, hiring from outside will usually shorten the learning curve and bring proven experience to the team. This ultimately helps the broader team as their exposure to these new skills raises everybody's value and potential. 3. Do Both: We need to do both internal development and external talent acquisition to manage the best possible team. Keep growing your internal team by providing new opportunities and challenges, while selectively recruiting outside talent to fill knowledge gaps and bring in fresh eyes. This way, I keep our internal culture strong, ensure continuity / grow loyalty and still gain a fresh perspective when you need it.

Start with a Total addressable market (TAM) * share of TAM you can get in next 3-5 years *confidence level *Revenue per user per year * 3-5 years. In the RICE framework, you would divide TAM * Share of TAM (influence) * Confience/ Effort to then help prioritize. (Desc) Calculating Share of TAM you can get in next 3-5 years is a art more than science. Do a SWOT analysis for yourself, incumbents in the market, if any and emerging players. Also keep in mind that market/users may not always be ready to adopt. So factor in the barrier to adoption/switching costs. Confidence level is based on your ablity to execute and deliver results- ship great products, great customer support, sales channels, marketing (even if lo-budget). Do you have the right team to get this done? Is the technology there yet? Are there high risk dependencies?

Going from an IC PM to a manager role was one of the most gratifying transitions in my career. Having been a manager before in a different context prior to becoming a Group Product Manager at HubSpot, I had some prior experience leading teams and operating in an environment with broader scope and complexity that helped ease the transition. That said, I do recall a couple of things: * Saying no to your pet rock: As an IC PM, you’re the biggest fan of your own product ideas first and foremost. Given my drive for intellectual honesty, I’ve generally taken pride in my ability to arrive at the best possible answer (even if it’s not originally my own) throughout my career. I do still remember early on as a GPM saying no to ideas I thought were great in the past was a practice of self-restraint. Fortunately, this comes naturally now. Now my role has shifted to ensuring teams are focused on the most impactful work, and having strong empathy for teams when we have to say no to the incredible ideas they harbored. * Finding the right cruising altitude: Within the context of HubSpot, there’s a Product Lead player-coach role between PM and GPM. During my time as a Product Lead, I found it challenging and thrilling all at the same time to be at the right cruising altitude depending on the task at hand and who I was communicating with. The way you communicate with the team you’re PM-ing is probably not the same way you would communicate with executive leaders. * Finding your people: This is something I recall from shortly after I shifted to GPM. As an individual contributor (IC) PM you develop very deep relationships with the designers and engineers you work with day in and out. You’re in zoom meetings or on slack with them most of the day. Especially in a hybrid world, it took me a moment to shift my mindset to a broader definition of team and intentionally spend more time with the PMs and peers in the product leadership team. Fortunately, I love building new connections and HubSpotters are very warm and eager to meet new folks so this was a fleeting moment. I’m sure there are a lot more, but these were top of mind.

When I prioritize or stack rank a list of items, I typically find it helpful to understand how each item can (a) deliver customer impact and (b) increase engineering happiness. Additionally, I also find it helpful to understand each item's level of (c) feasibility, (d) urgency and (e) effort. I weigh customer impact and engineering happiness at 50:50 -- after all, you need to make your customers happy while also keeping your team excited. Things that are less feasible are often pulled down the list. Whereas things that are higher urgency or less effort might be pulled up the list. At the end of the day, prioritization is an art.