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?

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.

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.

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.

If you know that customers are not willing to adopt your solution, that's a bad spot to be in. 1. Re-evaluate what led you to the decision to build & when to do it. Was there a gap in your methodology, or a piece of research that led you down this path? How can you avoid this for the next piece of strategy planning? 2. Don't hope for better adoption -- test and prove this out. Can you get a high quality signal that customers will adopt, e.g. customers will pay you now for access to it? 3. Is there a wider org that will bear the cost of holding this solution, and values it for reasons other than direct revenue?

Collaborating with Product Marketing is a key part of any product's success. In smaller teams/companies, that role can fall on to the Product Manager directly, whereas at bigger organizations that is a more dedicated role. I am fortunate now at Cisco to have access to some of the best product marketing resources in the business. The work that we do together from product strategy, execution planning, and external marketing helps ensure our business objectives are met and made visible within our specific market. We work closely throughout the GTM process and fostering this relationship is one of the key components to a solid product launch.

Taking a step back, I think the 1st PM needs to act a lot like a head of product in the early days. The ones I see that do well for their company (and themselves) typically focus on doing 3 things well, where others only do 1-2: 1. PM Execution * Typical activities you expect from a PM i.e. research, talking to customers, ideation, roadmap * This is foundational, but I think you will likely fail or at least get overlooked for leadership opportunities if you only spend time on this 2. Building the PM playbook * A key part of establishing the function is to determine the stage-appropriate processes, tools and people (hires) needed to achieve our goals * By owning the execution piece, you have an unfair advantage (and incentive) in shaping what the playbook should look like * If you can take most of this off your founders' plate, IMO you almost instantly distinguish yourself in the top performance quartile * You will also have greater control of your own destiny i.e. who joins the team, how prioritization decisions get made 3. Stakeholder management and education * Expect to spend 1/3 of your time (ideally not too much more) aligning with key stakeholders not just on what will make it in the roadmap and be shipped when, but also on how decisions should get made, and why there is a business justification for certain resources to achieve your goals. * In a startup, your leadership and key stakeholders probably have a limited understanding of PM best practices. In fact, they may have a (somewhat biased) view that a lot of it is unnecessary red tape that will slow down execution. Know when to push back and when to optimize for speed of execution and document learnings later. * I think the best founding PMs think like mini-CEOs: they scrutinize the business value of features (output) as well as the inputs (imagine this is your own $ or resources). They push back and say no when it's needed, and they're flexible enough to update the playbook and processes as teams grow. To answer your question more specifically, here's a simple sequence I'd use to prioritize my startup product roadmap from first principles: * Align on north star goals: * Where do we need to get the business metrics to be in the 6-12 months in order to raise our next round of funding? (or whatever the company north star is e.g. reach profitability) * As a result, where do we need the product metrics/behaviors to be in the 6-12 months in order to raise our next round of funding? (or whatever the company north star is e.g. reach profitability) * Work backward from north star goals to your current reality: * What are the 3-5 key jobs to be done that our customers come to our product to achieve? * How well does our product help customers complete these jobs to be done today? * What customer behaviors do we need to see in the product for us to know this is true? What product KPIs/metrics can we use to measure and back up that these behaviors are really happening? * Which business metrics (e.g. revenue, retention) will this impact? * Other first principles I'd think about: * Leverage the fact that your team is smalll to talk to more customers. You should become the expert on your customers 'jobs to be done' and current workflows. This will give you all the ammo you need when having to confidently decide, slice, and justify your roadmap. * >50% of the time, in the early days, doubling down on features or a product area that already works (i.e. has usage) will yield better results than shipping a shiny new feature. Communicate this accordingly to your stakeholders. * Be very clear about whether a feature is to play offense or defense (i.e. filling a gap with a competitive product.) There's nothing wrong with either, but a large lack of either signal you are either focusing too much or too little on the products you are evaluated against.

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

A great product manager starts not by convincing people of value, but by listening and exploring problems faced by their customers and team members. So, start with understanding what challenges your partners are facing - they can range from engineering-specific issues to business performance. Pick a few of these problems that seem approachable and explore them deeply, partnering closely with the people on the team responsible for them. Then deliver an improvement. It does not have to be a complete solution - but a measurable improvement that you were able to design and implement with your partners. Getting points on the board together and celebrating a shared win is the best way I see product managers that are new on the team quickly establish their value and build reputation as a strong team member.

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.