Product Management Career Path

As a first PM, you will need to be very judicious with how you allocate your time and resources. In fact, I think that’s true for larger companies as well. There are always going to be more ideas than resources available. As a product manager, you are responsible for translating the company’s vision into a roadmap so your first priority should be internalizing the company’s goals. Is it to drive sign-ups? Increase retention? Increase MRR? Or something else altogether? Narrowing in on that top goal helps to weed out work that may be less relevant. Once you’ve identified the top goal (there may be more than one), filter out any initiatives that do not map to this goal. The exceptions being pressing engineering initiatives (i.e. a platform upgrade, reducing technical debt etc.) or time-sensitive projects. Hopefully, you’ve been able to narrow down your list through this process of elimination. This is where a prioritization framework will come in handy. My go-to is the impact/effort matrix. It is very similar to ICE and RICE but simpler and more visual. For each initiative, assign an estimated impact to a measurable goal and a level of effort. Make sure to collaborate with your engineering and design counterparts when evaluating each initiative. This will reduce the chance of your own bias getting in the way and lead to better prioritization. For those initiatives left on the cutting room floor, think of a way you could still make some progress—is there an MVP you could run to learn something while the teams are working on the selected initiatives? There might be a low-cost way to validate assumptions via user research or data deep dive so that by the time you go through this exercise again, you are able to make a more informed decision.

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.

There are many great approaches to this question – and to some extent, it will depend on what the company values. If you're a first Product Manager, it is most important that customer needs / expectations are at the forefront of any framework.  With my teams, I sometimes like to use a graph, where one of the axes represents customer impact (how much does this product or feature postively improve their lives?) and the other maps effort or investment. That will give you an easy 2x2 where there is a clear set of high impact, low effort/investment things that represent quick wins. You'll also have a category that points to high impact, high effort/investment that require deeper exploration. Another approach I've seen popular in some areas is defining features as table stakes, nice-to-have, or surprise-and-delight – and scoring from there where current offerings stack up, compared to market. While there is no question we must offer table stakes, how the company approaches the other tranches of value will depend on the company's point of view on the market, the team's capabilities, differences or nuances in the customer base, and overall ambition.

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.

First PM in a company! I have not done it, nor have anyone in close network to have a good understanding. My guess is that they have to establish right roles/responsibilities on what to carve out from the CEO. Perhaps focused on scaling up product for next million users (or take on next set of enteprise clients), or execution focsed. Do take this with a grain of salt as I am guessing based on when should a CEO hire their first PM.

When you are the first PM, you are straddling several priorities: 1. Finding product market fit 2. Scaling the team 3. Scaling the product The biggest failure mode is trying to do 2 and 3 before you do 1: As the first PM, your foremost priority should be to establish product market fit. Distibuting that effort across more people dilutes the effectiveness because information gets lost along the way. Once you enter scaling, things become more complicated. Here the biggest failure mode is becoming your own bottleneck and entering what I call the doom loop of hiring: The less time you spend on hiring, the more you become a bottleneck, and therefore it becomes harder to spend tie on hiring.  So the crux is: Figure out if you have product market fit (many great posts about how you know) and then dive into hiring before spending too much time scaling the product - even if it hurts.

In my experience a prioritization framework is foundational to establishing a great working relationship within your own team and stakeholders. I'd also argue that if executed well in the beginning, the framework may not change much regardless if you are the first or 10th PM at a company. In fact, it may be a bit more straightforward as a solo PM since the prioritized list of needs and deliverables is a direct negotiation between you, stakeholders and your delivery team(s). As the product organization grows you'll notice that blockers, dependencies and enablers exist within your own product peer group as much as your business and engineering partners. Product teams even become each others' stakeholders along the way.  As the first PM, you should always establish ways of working and a framework for how the prioritization process will run: how you collect and understand requirements, validate impact, align on definitions of done, agree on and then communicate a prioritized delivery plan. I've used different versions of the RICE and MoSCOW methods in the past, which I suggest you look into.  Don't skip out on doing things in a documented and structured way because you are riding solo, trust me it'll pay off in the end :) 

There are a few different vectors to consider here. There is the effort/impact matrix, which is pretty good at helping identify low hanging fruit - essentially mapping out potential workstreams on a 2x2 matrix (High effort/high impact, low effort/low impact, etc). This can help cut through the noise as a good first step, but isn't the only thing you should be considering. Other lens I apply are things like: * Customer - how many customers does this serve? VIP customers? Is this a want or a need? This gets to the "impact" part of the 2x2. * Urgency/timeline - how flexible is the schedule for this? Is it immovable (like compliance/legal requirement) or can we work to create space on our roadmap (perhaps deliver a smaller milestone, negotiate a different delivery, etc).  * Scope - can we potentially cut scope or re-scope to help move quicker (example: do a proof of concept to answer effort questions, running an experiment to get an early read on impact, etc), or is there potentially another way to solve the problem that we haven't considered. Change we change the "effort" calculation? * Expected outcomes - this gets back to the impact, but you will be surprised, especially in an org that may not have a product presence, that there may not be a clear definition of success or outcomes a project is trying to achieve. Part of the role is to apply process and discipline in this area.  Keep in mind that in organizations where Product is nascent or does not exist, oftentimes there is no one defining the "why", and potentially there is a lot of discussion on the "how" and the "what." One of the biggest impacts you can have as a product manager in an organization is being very clear on the why. You may find that the team is focused on the wrong things (e.g. focusing on building "bright and shiny" features rather than things that customers may actually care about, or doing custom work for a particularly vocal customer, etc). Part of the hard part of product management is saying no to things/pushing back, making tough choices and potentially killing projects that don't provide clear business value.     

Thank you for the question and I'm sure this is exactly not the answer you're looking for which is, "it depends" You're balancing building trust and relationships, understanding your users and the business, and likely an evolving company strategy. So the question you need to ask yourself is what are you optimizing for? The runway of your company is critical to consider, but I always lean towards how might we prioritize learnings and building trust to build out a strong product roadmap

The fundamentals of prioritization are not too different when you're the first at a company. But in the early stages of a company or product, it's even more important to focus.  At an early stage company, or a new product at an existing company, chances are you're finding product-market fit. When thinking about prioritizing work in that context, you need to be crystal clear on the metrics that matter, and laser focused on moving them.  In my experience, developing and testing hypotheses is a great framework for this stage. You simply can't afford waste, so understanding what you're trying to achieve, and then explaining to yourself why your proposed feature/deliverable/problem will achieve that outcome, is worth spending time on up front.  For everything that you're planning to build, take the time to create a test plan. And always look for the fastest way to disprove your hypothesis.  Here's a simple example plan: 1. Hypothesis: "if we do x, we will achieve y" is a good format. 2. Method: How will you test this? If you can do it without building any software, so much the better.  3. Metrics: How will you know if this passed or failed? Be rigorous here! Failing an idea early can save you later. 4. Results: What happened? Document and analyze the actual against your hypothesis. 5. Call it: Did it succeed or fail? Invest in the successes, learn from them, and keep repeating the cycle.  

This is a great question about how to pave the way for two things: product strategy and product management execution. I can see this being applicable to not only first Product hires at start-ups, but new product areas a company has never pursued before. There are a few mechanisms/processes I would establish as a first priority:  1. Establish a feedback loop with the top customers, internal users, and market analysts (product mgt execution) 2. Identify the top 1 or 2 business metrics you are looking to influence (product strategy)  3. Create a cadence for a roadmap to release notes that can be published publicly for internal and external audiences (product mgt execution)  4. Review the existing competitive landscape and understand your product market fit (product strategy) 

The product manager's primary responsibility is to ensure that the right product is delivered to the market at the right time. In order to do this effectively, you will need to establish a framework for prioritizing needs and deliverables. This framework should take into account the company's overall goals and objectives, as well as the needs and wants of your customers and stakeholders.  There are a number of prioritization frameworks available with RICE, Value versus Effort, and Kano Model being the most popular ones. You can pick any of the popular prioritization frameworks or even create your own. What matters is using a systematic and structured approach to prioritize your needs and deliverables, so that you can deliver the right product to market at the right time. Another thing when picking a technique to keep in mind is to pick one that is easy to use and will fit with your company's culture and can eventually scale as the product team grows. 

To make this decision, I think of opportunity, ambitions, passion, and time: 1. Opportunity - obviously there is a matter of compensation, but there is also an opportunity for professional growth. For example, joining a startup allows you to grow much quicker -- you will be wearing different hats and working much closer to the company leadership. You will make a lot of mistakes, but the learnings will be much greater. 2. Ambitions - depending on where you at in life, different things might take a priority and it's important to keep that in mind e.g. you are starting a family or want to work remote from an island in Hawaii. If you are ambitious and feel that you can do more, you can tell your manager you want more work or go to another company or start a project/your own company. 3. Passion - you can gain your initial experience in one company, but if your heart is in the other place e.g. music, you probably want to consider getting a job at Spotify or Apple Music. That is where you will have the most fun.  4. Time - from my experience, it takes ~2 years to get up to speed with a new product area and make significant contributions. That is why it's common to see PMs going to other companies or seeking other roles within the same company. This allows you to grow and shift gears a little. In my 5 years at MuleSoft for example, I worked on 3 different product areas -- I've learned how to build marketplaces, identity products, and API platforms. 

There are some absolutes, which may be self-evident, but I'll still mention them for the record: disrespect, discrimination, excessive stress, unreasonable and unhealthy workload, workplace toxicity in all it's forms, the company is unethical or is visibly tanking...and many more.  Otherwise, I suspect the most common reason to leave might be simply put as: a better opportunity elsewhere. Now, this is a very personal calculus that becomes harder if things are not exactly terrible. Perhaps you are holding out for the promotion and it is taking longer. Perhaps the economy is too "risky" at the time. Perhaps you feel like you have something more to learn in the current role that you want to then leverage in the next job search. On some level, any reason is a fine reason to stay, as long as you know that you are consiously making the choice and it is a choice that in your best estimate takes you to where you want to be in the long-run. Most importantly, you don't want someone else to be making that choice for you. It is easier to get a job while in a job vs. when out of a job. And how do you ever know what is a better opportunity elsewhere? So network, look passively, field exploratory calls. From that perspective, it is never a bad time to be passively looking and neither is it necessarily time to leave.  In my own career, I've had situations where I started looking into a new role within a few months, due to some of my "absolutes" above being violated. In practice, I stayed on for many years, despite getting viable offers roughly every 6 months, i.e. it wasn't innertia, but a consious choice taking into account an ever-evolving org, company, and economic backdrop. 

There are a couple of factors to consider here: * Are you learning anything new in your current role? If not, would staying with the company, even if it is in a different role, or a more senior role (be that IC or management), satisfy your learning? * Do you enjoy the domain, vertical, and business model of the company that you work for? * What are the company's growth prospects (or if a startup, prospect for success -- however you define success?) Be very honest and don't just take company management's word for it. * Are you excited and passionate about the product that you're currently working on? * Do you enjoy the people that you work with? (your manager, your peers in engineering/design, your peers in product management, etc.) If not, is it likely to change over the next 6-12 months or whatever is your window of tolerance? * Are you and your ideas respected and given a fair shake? How much autonomy do you have versus how much do you want? * Does the company's appetite for risk match your appetive for risk? (e.g. are you working on a horizon 1 product when in reality you would rather be working on a horizon 3 product) There is no right or wrong answer to these questions but I hope they will spur an honest assessment about what is tolerable (and also if currently intolerable, is it likely to change to tolerable within period of time) versus what is a hard red line for you.

Typically, promotions are the result of an individual's performance and business needs. In other words, it's hard to make a case for becoming a Director if your area can be covered by a single Sr PM, so both you and your product area need to grow.  PM Directors are also people managers who hire and build a team of other Product Managers. Having good people skills is important but you also need to be a great PM, so you can lead and help your team of Product Managers grow.  Finally, shifting to be a Director shifts your time allocation -- you spend more time in meetings working with your team and less time creating content, PRDs, etc. 

This is a mix of both seniority as well as working at a high-growth private company but clarifying R&Rs to ensure teams are built to maximize impact while minimizing management overhead is something I have a much deeper appreciation for now vs. earlier in my career when I focused more on getting a launch across the finish line.

A few of things: * Know what, when and how to delegate. Delegation has such a negative connotation in industry (being seen as letting garbage flow downhill) but I believe this is because so many managers are poor at the mechanics of delegation. As a PM director, you have to learn how to delegate problems to be solved and not orders to be fulfilled (a/k/a solutions) and be comfortable with the ultimate solutions even if they weren't what you would have built as an IC in the shoes of the delegate. You must also learn to see delegation as the manner in which you are granting autonomy and growth opportunities to your direct reports and not as the way to hand off dirty work that you would rather not do to "underlings". * Frequent contemplation of organizational design and areas of responsibility. Every week I am thinking about organizational design and at least quarterly I am having discussions with my peer leadership team in engineering and design to talk about whether we are a) staffed appropriately in the areas we need to be; b) whether we have the right skillsets and mix of seniority on our teams; c) whether we are optimizing for the strengths of PMs/eng leads/design leads while also giving them opportunities to stretch and grow in their current roles. * Employing a variety of communication styles with a wider range of stakeholders. We all have our default, natural communication styles (for example, my management style with my direct reports defaults to Socratic) but a director has to know when to switch styles based on the recipient of the message, their level of seniority, their personality, etc. -- and be able to intuit this very quickly in the course of delivery. I have had to force myself to be more direct ("Crucial Conversations"-style) when a softer message isn't making it through, for example. A corollary here, particularly when dealing with senior stakeholders: knowing what to spend one's political capital on, and when to pull back.

1. Storytelling. You need to be able to tie many disparate pieces of product work - user needs, business goals, technical limitaitons, competitive landscape, innovation opportunities - into a coherent, compelling narrative. A director can fill in the blanks in the following sentences with ease: "This year, my team is trying to achieve _____ because our comany needs to _____. In order to reach our goal, we need resources of ______ , focus on ______ and ______ and support from ______." 2. System thinking. A common mistake I see in PMs is trying to get *their* work done without thinking through the impact it has on adjacent teams - think, I need to meet MY goal and have MY feature on the home page, without consideration for a global optima. Directors need to think at least one level of abstraction about their own area. Who else will be impacted by your work? Is that impact good? Does it add up to greater good, or is it a local optima?  3. Inspire others. The difference between a manager and individual contributor PMs is that the goal of individual controbutor is to "get sh*t done", and goal of manager is to "make sh*t happen". You need to be able to achieve goals through your own work AND the work of others on your team. This is only possible if people can be inspired by your vision, integrity and leadership. 

1. Exemplary people leadership (ability to bring people along) 2. Strong relationships across various functions (including non-R&D teams) - get done what's needed to solve a problem, and get products launched. 3. Maturity to know when to switch course for a product line, drive tough decisions, and leverage #1 to bring your team along with you in that decision.

1. Communication 2. Execution 3. Domain expertise I'd add stakeholder management as an important one but I can only do the top 3 :)

My answer to this depends a lot on whether the "director" title includes people management or not. Personally, I believe that it should, and that the IC (individual contributor) track should only use the titles PM 1-3, Senior PM, Staff PM, Principal PM, Distinguished PM, etc. But I don't make the rules for the industry :-) and I recognize a lot of organizations use "director" to mean IC as well. I am going to answer the question assuming you mean that it includes people management. Accordingly, the top skill you want to have is a) knowing that you want to manage (a/k/a model, coach/mentor, care) other humans and that you don't just want to be an IC with more influence, and b) learning how to do that, or at least walking into it having some kind of a philosophy about management. I don't believe it's necessary to have prior experience as a people manager before becoming one (otherwise it's a chicken & egg situation and there would never be any people managers!) but demonstrating coaching / mentoring / feedback behaviors with your peers is a great way to gain these skills before you manage other people. I can't emphasize the foregoing enough because if you do not truly care about understanding human beings in general, what motivates the specific humans on your team, and how you can coach them to being better PMs, then you are going to view the "process" of managing people (HR reviews, hiring / separation duties, compensation management, 1:1s, etc.) as drudgery rather than tools to build an amazing team. I would say that the other two skills that are critical are: * Being able to drive change through your team, representing both their plans and their achievements to senior management and advocating for them, and * Executive presence and gravitas, including the ability to remain level-headed and confident no matter the obstacles in front of you, to give both your team and your management the confidence in you as a leader.

The biggest struggle I have observed is related to transition from an individual level product craft growth to growing that of a group. Andy Grove in High Output Management said "Managers are responsible for increasing the output of their organizations and neighboring organizations they influence". Read this sentence again and again. The learning curve is in learning how to optimize for the outputs of your team vs. your own. This means that you need to make trade-offs across your teammates and their areas, as well as help each of them grow as much as possible.  My recommendation is to read up on team management in all contexts - business, military, sports have great writings on it; there are also many articles and videos from leaders of all kinds. Then, ask yourself (before you were to manage a team), how would I change my prioritization frameworks, rituals, interactions, communication style if I were to optimize for an output of a team of PMs. You can even hypothsize about it using your existing team - if you are a manager tomorrow, what would you do differently to optimize for the greatest output?  Simply thinking and writing your thoughts down on this topic, as well as honing in on skills I mentioned above in the "director level" answer should help you prepare for the transition. 

Love the proactive thinking and the desire to excel :) Not sure if the learning curve is any steeper but there are a few things that can support career growth: * Master the craft for what is required of you in the current seniority. * Get exposure to delegating more work, creating leverage across different teams, and see if you are able to 'let go of the detailed tasks' but still bring a beautiful product to life with your team. * Get exposure to market maps, strategy documents, start asking thoughtful questions in various forums with leadership - not to be the loudest voice but more to build the sharpest brain. * Invest and re-invest in building relationships with cross-functional partners across the company. Learn how they think about their work. * Try unblocking others - what does it take to pinpoint what is holding back someone and how can you help them be successful? What is your personal style as you do that?

In my experience, the learning curve happens in the current role, as a prerequisite to transitioning into the next. You have to be operating at the next level already and there really isn't an easing of the transition beyond that. For example, managing wider scope, solving harder problems, navigating trickier interpersonal dynamics, connecting more "dots", communicating with more clarity on more complex matters, and influencing more people and outcomes, are among some of the skills needed at every PM level, but to different degrees. As you showcase these skills you are already solidifying the foundation for the next level. One of the biggest learning challenges can however come at later levels - when transitioning from IC to manager (irrespective of the accompanying title), partially because it is a binary situation. You are either a manager of people or you are not; there is not much preparing or gradual transition. Relatedly, many PMs are seeking that check-list, that when done, spells promotion. Consequently, one of the most frustrating and non-actionable things that managers can say is "you are not ready yet", perpetuating a bit of the feeling that there is some transition or steep learning that one must overcome. Often it means the manager is not ready to do that for you but is uncomfortable giving you specifics. Or it is not possible in the current org strucure. Sometimes, they just don't know themselves, but they'll know it when they see it. Perhaps, that is a big hint. Observe how others at the next level are operating as preparation. How big are their projects? How much more do you have to know or do? The criteria can be very different by company, that's why it's important to know any published leveling criteria. But generally, even then, there aren't a lot of clear-cut check boxes. Sometime the criteria are only in your managers head. I once had a manager tell me that if I grew my product to $50M or $100M in revenue it would get me promoted. (My answer was to remind them that we were working on 5-year incubation, hence low likelihood of multimillion dollar outcomes on any reasonable timelines, and that this criteria should have been articulated a lot earlier in the job decription. Plus there were plenty of examples of promotions without that criteria - so the aforementioned criteria disappeared from our conversations.)  In all cases, cross-reference everything official with what you actually see happens day-to-day and what behaviors or results are rewarded at the next level. Perhaps, the steepest learning curve is learning what specifically gets you promoted at your particular company and with your particular management chain.

It can definitely be a steep learning curve, because at Staff+ PM level you are expected to have strengths in one or more areas of product management that aren't often exercised at lower levels. Some examples: * Having a much wider aperture and being able to develop and sell portfolio-level (not just product or feature-level) product strategy that can touch other areas of the company * Assessing and making build vs. borrow vs. buy recommendations & understanding how to work with a channel/partner/business development team * Coaching and mentoring other PMs and reviewing their work * Portfolio-level goal setting and roadmap management * Organizational design (how to do it, when to change it, influencing your engineering & design peers to restructure their org structure as the product evolves) * Preparation of executive-level communications (how to convey only the most important information in the most concise manner possible) The good thing is that you are not expected to be excellent in each of these areas right out of the gate. But it helps to do a couple of things if you are aiming for Staff+ IC in your career: * Pick one of these areas and figure out how you can proactively pick up opportunities to learn and improve now. If you plan to stay at your current company, it helps to pick something that is a gap/weakness in the organization to make yourself more valuable. * Focus your reading / learning / professional development / networking in the PM community towards that topic, so you gain some outside perspective on it. * Be transparent with your manager about your career aspirations and what you are doing to level up in at least one of these competencies -- and hopefully align that growth with something that your manager needs in the group. I will mention one exception to all of the above. It is possible at some companies to become Staff+ PM simply by having more historical and domain knowledge than anyone else such that you become the "product oracle" for that area. In these situations, a breadth of skills outside of that domain knowledge is less necessary. Just remember that there can only be one oracle; once you choose that path, it is hard to get a Staff+ PM job elsewhere unless that company specifically needs the same wealth of knowledge.

Startups are all about speed. To move fast, you need to know where you are going (aka what to be ruthlessly focused on) and allocate the most of your time/energy to that. Easier said than done, right? One thing that helped a lot in my early startup days was my framework of "One thing I am going to fail today".  Once you establish together with your team what you are focused on this week, month, quarter - write that down and look at it every day when planning out your work. Then, notice things that either don't help you move there, or things where your quality of deliverables will not be critical to the area of focus. Then, tell yourself (and the team, if you so prefer) - I am going to focus on nailing X today. I will do an okay job on Y, and I am going to drop the ball (or fail) Z.  Breath out, and go stay focused. 

In a startup, the R&R is faintly defined at its best. You naturally get pulled into 1000 different things - that is both fun and a challenge :) A few things that you might find helpful: * In the beginning, it is good to get exposed to a variety of different topics. It can be overwhelming for sure. * Once you understand the organization's needs, ask yourself "What can I do to make our company successful?" (and I hope your equity motivates you to ask this question each step of the way). * The answer to that question will help you in 1) Defining more R&Rs across the company 2) Seek the resources for the stage your company is at (e.g. do you really want to add another project management layer or would rather just do it yourself if communication lines are easy?) and 3) Act like the owner for the areas where you can make the most impact!  Some tactical things to do: * Set a goal/theme for the week - if there is one thing you could accomplish that week, what would it be? * Proactive and recurring calendar blocks to get that one thing done. * Consider even setting a target for the day-to-day requests that you feel good about - e.g. personal SLAs for when can you get back to an email request. One thing that I like always coming back to is that day-to-day tasks will never get over. One task will simply get replaced by another. It is so important to have your boundaries, prioritize and create focus time for what will help your company the most.

Actually, no differently than managing the 1001 questions and tasks shot at you in a large company :) A PM wears many hats. If any one area takes over disproportionately, the risk is that you are no longer doing the job of a PM. Some common blurring of the boundaries is when PM is acting to fill gaps that are normally entirely different functions: - Project manager - QA - Technical Support - Technical Writer - Trainer - Solution Consultant - Marketer - Data Analyst, etc. Write down the CORE PM responsibilities, that should NOT be owned by another function. This is how in theory your PM role is meant to drive value. Write down how much time you are currently spending on each and what your total is on core PM activities. Next, list all the other things you do that should be owned by someone else. How much time do you spend there beyond a reasonable amount that PMs would normally have to dedicate there? The difference between time spent elsewhere vs core PM dilutes your role and masks gaps of equivalent or greater magnitude in other departments.  Estimate, if resources were not a limitation, how many additional people would need to be in these stakeholder areas such that end-to-end things run smoothly without you filling the gaps. Articulate what would get done, if you were not filling this gap, but were instead focusing on product management. This is your recommendation and ask of your management chain to rebalance things such that you can do the best possible PM job. You may hear that resources are in fact a very big limitation and the status quo remains, but at least you now have a clear indication of the company's priorities - e.g. all hands on deck for new sales over new product development, bug fixes, or launches. That is OK, but then the decision is for you, if you want that for yourself. Chances are, however, that it will give leadership some pause and potentially drive some change. I've been through 3 companies (startups and large companies alike) who all swore up and down that they were philosophically opposed to having a project management function. That is until we repeatedly showed how 30%-40% of PM time was spent on project management and no product acceleration could be had unless we either added more PMs operating at partial capacity (expensive) vs getting 1 technical project manager (less expensive). I even had a startup founder snipe about how PM was tied up with eng in expensive meetings without asking what the meetings were about - they were about tickets, bugs, backlog grooming, and status reporting. We got new ticket/bug management tools and a TPM shortly thereafter :)

I've definitely been there! As you correctly intuit, your first order of business is to buy yourself some time to develop a strategic point of view and a roadmap that supports that it. Obviously that means you're going to need to spend time meeting with customers, prospects and customer-facing teams inside your organization, synthesize the learnings, and develop that roadmap & strategy. In a startup, you have to do this at a much higher tempo than at a more established company, but it's essential that you convince your direct (and indirect) management that investing in these things is going to pay off down the road in time saved / lower risk for the startup / more satisfied customers / whatever rather than just continuing down the feature factory path. What's important when you have that conversation is to be explicit about the things you are going to drop or do less of, like literally saying, "I am going to do less tactical project management, status reporting, etc." Invariably, some of your peers who have expected PM to do these things are going to be disappointed at the lower level of "service" which is why you need your management to buy in on your shift towards becoming more of a strategist rather than a tactician. This may need to be a shift that happens over a couple of iterations particularly if the organization is not used to strategic product management (you can't "big bang" stop doing project management if the company doesn't trust you to deliver high-quality strategy yet). You don't mention the reasons behind why the startup has become less sales-led and more product-led. Whatever those reasons are (e.g. we are good at bookings but our churn is really high when customers find out our product falls short of the promises), you want to be clear-eyed in understanding them and tying any communication around your shift in focus to those issues. Also, there will obviously be one or more individuals at the company driving that change from sales-led to product-led. Ally yourself closely with those individuals, get them on board with your plans, have them amplify your strategic work products, and (particularly if they are more senior to you) use them to deflect the noise from folks who wish you would just spend more time doing project management.

Having worked in Product in completely opposite contexts, the most valuable soft and hard skills depend on several factors, including product maturity, organizational maturity, availability of supporting functions (e.g., Product Operations, Product Analysts, etc.), and company cultural norms.  At WooCommerce/Automattic, the expectations I set for PMs are: 1. Drive the creation and execution of product strategy for your focus area. 2. Lead multi-disciplinary teams through the development process. 3. Cultivate direct connections with our customers. 4. Increase our success in aiding our customers’ success. 5. Contribute to good business unit leadership decisions. With this context, I would say the most important soft and hard skills for PMs at WooCommerce are: Soft skills * Proactive internal communication – up, down, sideways (to peers and cross-functional collaborators). * Spearheading cross-functional collaboration – from defining an inspirational "why" to project-managing a variety of stakeholders toward getting things done. * Deep listening to customers – this includes taking a genuine interest in their feedback, and sometimes hearing what is not said but implied between the lines or in non-verbal cues. Hard skills * Functional expertise – most PMs come from marketing, engineering, or design backgrounds; being able to draw from an area of mastery will inform your POV (and give you one less area to ramp up on!). * Goal setting and accountability – this one is a bit operational, but being able to translate product into measureable impacts will be essential to prioritization and making a solid business case with your teams. This has, implied in it, analytical skills, or at least confidence in quantifying outcomes. * Industry or subject matter expertise – Another thing that will inform your POV and reduce ramp time.

* Soft skill: Great product managers can seamlessly adjust their communication to match their audience. As a product manager, you'll speak with people in different roles and varying levels of expertise in your subject area. It is essential that you can communicate your ideas and exchange information with everyone! I really love the perspective shared by Camilla Boyer in a recent talk at GitLab about communicating with emotional intelligence https://www.youtube.com/watch?v=3pZoNORrDjU. Product managers should approach conversations with the mindset of providing the information their audience needs instead of focusing on what they need to say. * Hard skill: Iteration is one of the hardest things to master, but it is essential for providing value quickly and getting feedback to improve your product. GitLab has great resources to help improve this skill. Check them out https://about.gitlab.com/handbook/values/#iteration! One thing that has really helped me improve my iteration skills is to think of my product as ever-evolving and that what we release is not the final version. If a set of changes are an improvement to the current experience and there's a clear roadmap to build upon that experience, then we should release it even if we are not done! 

As a general manager, I own specific business goals and outcomes that I need to achieve, and am responsible for on an organization level. Those goals are very specific and measurable, so I always know where I stand on them. As a team leader, I measure success through my team's happiness, proficiency, ability to grow their careers, and our ability to scale the team (e.g. we can quickly and effectively onboard new team members and set them up for success). As a product manager, I tie my own evaluation of success to value I deliver to my customers (measured both qualitatively and quantitatively) and to learning - I love to learn as most product people do, and how much have I learned and whether I have gotten a better as a PM, teammate, team leader and general manager is the lens I see my succes thorugh. Those success measurements have been fairly consistent over time, but I started practicing them in "chunks" - first the PM set when I was an individual PM, then the leader one when I started managing a team, then the GM one when I started running a business unit. 

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.

This varies so much from company to company but my general lens while moving from PM to SPM: * SPMs have had at least one meaningful product launch in their career. * SPMs are able to cut across product lines, reach out to multiple PMs to identify dependencies, get buy-ins, and manage timelines for complex launches that touch various parts of a product ecosystem (vs. focusing on one siloed area). * SPMs establish a relationship with various stakeholders (including non-R&D folks). * SPMs can outline a broader business strategy and define a long-term vision for their areas (vs. PMs focus more on execution or on what's next in the near term). It is hard for me to define the stages of different SPM levels. Generally speaking, you can either start going deep into one specific product area (to get set up for an IC/Principle PM path) or continue working across various PMs to solve problems (to get set up for a manager/GPM path). In my opinion, as closely as companies can tie this to impact and the craft of execution, the more objective this becomes for promotions.

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.

In general, the progression from any level to the next is a matter of demonstrating increasing levels of skill in product definition, technical or domain expertise, ability to navigate and project manage increasing levels of complexity, communication, and ability to influence amonst others. Another way to think about this is that you are increasingly moving from "learning the ropes" to "knowing the ropes" to eventually "having invented the ropes". Much depends also on how formally the company defines the boundaries between roles, how flat the org is or conversely, how much title inflation there is. Most large companies have formal definitions of what the expectations are for each level because that ensures a common set of criteria for promotion. The criteria may not be well- publicized but they are not meant to be secret, so you should ask for them either way.  In a traditional PM hierarchy the PM and the Sr PM levels are typically early career levels. A PM typically receives a lot more prescriptive direction on tasks, they may cover one or more projects, and the scope is narrower. For example, running one experiment at a time, defining one feature as a subset of a much bigger system. While decisions are often made by more senior PMs and engineering partners, the PM is documenting the requirements, filing the tickets, and helping project manage.  A Sr PM has shown good judgement and is both able and trusted to operate more autonomously. This holds true for a progression to Principle, Director etc. The Sr PM is still focused on a specific area but takes on more complex functionality, is more actively defining the features and driving the full product lifecycle. They know the processes and support systems, they are able to navigate the org and increasingly more complex converations. They are increasingly self-aware and aware of context. They know when to ask for help or to check-in that they are on the right track. Both roles are focused on execution. In some orgs there are additional gradations within a level: Sr PM I, Sr PM II etc. Unless defined somewhere, a good proxy for any level progression is as mentioned above: growth in scope, increasing ability to influence and drive projects of increasing complexity, ability to communicate effectively, which means both the ability to drive alignment but also to diffuse conflict.

Check out my other answer in the AMA outlining the difference in skills between different PM levels. As for how do I know that someone is ready to take on a Sr. PM role, the answer is I can see them operating with a mastery of skills that I expect from a senior product manager, while their title may still not have a Sr. in it. Best folks always uplevel themselves a little faster than the title, because if you are a growth mindset person who always likes to learn, you will most likely outpace your title at some point. My recommendation is also to work with your manager as well and establish what are their expectations for a Sr. PM - they may have a different idea in mind. But getting to a clear list of what you'd need to do to get to a Sr. PM title in your org, and then checking in with your manager consistently on your progress is a path to get there.

Check out my other answer in this AMA to a question asked by someone from a construction industry. You can repurpose the steps I outlined in that answer to your situation. The key parts to figure out will be the WHY behind your interest in SaaS, a list of skills you have today that are transferrable into product management, and updating your resume/profile/interview practice accordingly. Good luck!