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?

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!

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

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.

I have a very simple framework for building 0-1 product - IVC framework 1. Identify: * The first step in developing any product or feature is to identify the user's needs. Hence, your goal should be to talk to as many users as you possibly can to understand what they say, do, think, and feel. This also helps you learn who you are solving for and who you are not solving for and create a problem statement 2. Validate * Building Conviction by testing Discovery, MVP, market analysis, possible conversion. During this time also you should be talking to customers to validate the problem and solution 3. Create: * Create the right team to build the product and also a plan on how you will bring the product to market.

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.

The great thing about being the first hire is something that is also great about Product Management: there is room for interpretation. My philosophy has always been more heavily focused on understanding how things operate current state, finding out pain points as well as the more successful parts of a product, and leaning on those insights to form your next steps. In certain scenarios, what a team may need is for someone to roll up their sleeves and do the work to keep the lights on for a product. It may be months before you can get the product to a comfortable enough place to think about weeks, months, or quarters ahead; however, that time allows you to gain knowledge of the product itself. In other scenarios, a product may be operating just fine, and your task will be to understand where it can go next. Your time will be spent with customers, stakeholders, engineering and others to understand the areas of opportunity that exist. You don't always need to reinvent the wheel or start from zero just because there was not a product team in place.

I have sometimes seen Product teams focus on impact instead of landed impact. And while there is a lot of nuance in that answer I think landed impact is often the most overlooked KPI or OKR or goal (however you like to call them). Teams will goal on number of users or shipping a feature rather than goal on the impact enabled by those metric. Take your typical B2B SaaS for instance. 200 active users of a feature on day 1 is an ok measure of success. But what really matters is what those 200 active users have achieved with your product. Or what those 200 active users have led to in terms of business impact. The visual below is a good illustration of what I mean: https://www.useronboard.com/imgs/posts/mario-water.png

* Resume: Usually, the biggest red flag for me in a resume is when either the candidate doesn't describe any impact metrics or focuses on a vanity metric, eg, if a checkout PM describes an increase in the number of payment page views instead of an increase in checkout conversions * Initial Interview: PMs are often advised to use a variety of frameworks for their interviews primarily to showcase a PM's structured thinking to a problem. This is good advice as long as the PM uses a framework for reference instead of answering questions with the framework alone. As a hiring manager, I am more curious about how you thought through a problem, what real-world challenges you came across, and what the outcome was. The idea in an interview isn't to understand a PM's knowledge of the various frameworks available but to understand the depth and breadth of their thinking in a real-world use case.