Subu Baskaran

If you are an entry-level product manager or a first-time PM switching from a different function, executing a feature end-to-end is the best place to start. During execution, one can learn system behavior and develop necessary POVs, such as user behavior and the jobs-to-be-done for the persona. During this process, a PM works closely with peers in the User Experience and Engineering teams, helping the PM understand how the team operates. Also, during interactions with customers and the sales team (B2B) at different product/feature launch stages, a PM can demonstrate their expertise in the feature and the product. Conversations with the sales team and customers are where product strategies and future roadmaps usually develop, outside of top-down, market-driven strategies handed down by leadership teams. Finally, starting with execution does not mean the strategy is the wrong place to start. In large companies, strategies are often vague and require cross-functional stakeholder approval, and it's a bit harder to establish your POV with members outside your team.

The answer depends on the size of the company. But if I generalize, if you are a new grad or new to the function, then your first job would be Product Manager. Then, depending on whether you are in B2C or B2B companies, there are different levels with slightly different titles. In B2B tech companies, the titles progress from PM to senior PM, Principal, and Director. As a Director, you typically become a people manager responsible for an area of the business. Some companies might even have titles such as Group Product Manager before Director, but these are layers with slightly smaller scope. The responsibilities grow wider and wider until you become a VP, where you become the single-threaded owner of an entire business. Again, depending on the size of the company and the promotion criteria, a candidate can typically spend an average of 2-3 years in a role. It gets much longer as you go higher up the ladder.

Technology can be a real competitive advantage. If your industry needs sub-second latency to monitor their systems, having a streaming architecture that delivers can make your product a no-brainer. Often, what's cutting edge today can be a drag within a decade. I have always looked at it from a customer's standpoint. For, I prioritize new product development to replace anything that is considered "legacy" when one of the following happens: 1. The overall market is shifting. Often, when a new technology comes along, it sways the market away from what customers are used to. Competing in a new era with old technology can harm the customer and the business. As an organization, when you don't embrace new technological shifts such as AI or new UI development practices, customers notice. 2. Customers are losing faith. Often, in mature products, the underlying technology may not solve customers' problems today. You start to see mature customers complaining of a lack of scale, performance, or out-of-the-box help, things that were not important five years ago. While often, one can solve such problems by optimizing the code or having better documentation for new customers who are not champions in your ecosystem, there will come a time when you have to make significant architectural changes to support these requests.

Stakeholders for mature products are typically large customers, experienced field teams (sales, engineering, support in B2B), and long-term product team members. Managing customer expectation: While there are many aspects to managing customer expectations, here are a few things that I have encountered working on mature products: 1. Hundreds of users within a large customer organization use the product daily and expect it to scale and perform to their growing needs. As PMs, it's our job to ensure the users feel heard. As the PM lead for a mature product, I often talked to customers and had transparent roadmap discussions, so they were confident we would deliver what was essential for them. 2. Users don't like change unless a new feature or enhancement radically improves their life. Remember, a problem for one customer might not even be a nuisance to many others. Managing team expectations: As a product leader, you serve the customer and the team building the product. While retaining customers is essential for business, product development teams can lose motivation to maintain a decade-old product, even one with a high ARR. I find that including senior/long-term team members in building the vision for the product is very helpful. They get a sense of belonging, have an ownership stake, and can even rally junior members for the cause. The other aspect of managing a team that has worked on a mature product is not giving in to some members' long-term biases. Even though they may have all the answers, I have found myself seeking clarity from others, which has helped me question the biases with a new perspective. Most people work with you when you question traditions or biases if you have the right intent, i.e., you are solving a real customer pain point. Even the most tenured team members come around when the stakes are high.

There is no one silver bullet for a product management candidate. If I were to look for specific traits, definitely high up on the list would be how long a PM candidate explores the “problem space.” Honestly, ideas are a dime a dozen, but understanding a customer problem and isolating the right pain point, in my opinion, differentiates an average PM from a great PM. Finally, remember that a PM's main job is to ensure we are building products for the right customer problem. So, having an exploratory mindset and curiosity about the problem space can provide an edge over other PM candidates. Note - other skills such as identifying solutions, prioritization, and collaboration with engineering, UX, and marketing are equally important and may be required to qualify as a well-rounded PM.

In short, have a long-term perspective on what you are building. As a senior PM, you are more inclined to ship faster. This might look great and temporarily get you the spotlight, but what ultimately matters is the difference it makes to the customer in the long run and how it impacts the company goals/metrics. Know that if you plan to build what your customer is asking, you are too late and playing catch-up with the competitors. Having a long-term perspective, such as where the industry is headed, how the landscape is changing, how your products give an edge to your company, and how customers are evolving, helps you build more long-term features and positions you as a natural leader.

If you are a new PM in an organization, my advice would be the following: 1. Be curious - learn as much as possible about the customers, users, features, and the system. Talk to as many people as possible and arrive at your point of view. 2. Make allies - Identify engineers, UXdesigners, and sales teams (B2B) that you connect with and validate your learnings periodically. 3. Question status quo - Once you have a particular POV, ask questions if something seems wrong. If it's new learning, admit it, but if the question helps the team uncover some kind of oversight, you have done a massive favor for your team. Note - Keep in mind, in a company with a history, there are many reasons why things are done a certain way and the team probably looked at many possibilities before going down a particular path. 4. Grunt work - Finally, do all the grunt work you can. Every document you write to a demo you give reinforces learning and establishes you as a product leader within your group. Attend all the meetings where engineers are talking about technical solutions, of course, if time permits. PMs often tell me they don't care about how engineers build stuff, but going through those discussions helps you appreciate the engineering effort and gives you a system-level understanding.

Skills vary at different levels of product management, similar to other functions. In large organizations, product management usually has two tracks: 1) the IC track - PMs can grow as individual contributors to director or even VP (depending on the company size) levels. Again, it's hard to pinpoint the exact skill level for a set PM trajectory as this varies from company to company. But at a high level, an entry-level PM with a good product sense and a curiosity to learn and execute an end-to-end feature is considered valuable. Once you have a couple of feature launches under your belt, and if you had paid attention to signals from the market during execution, you would have noticed your roadmap being constantly tested by customers and sales teams (in B2B). The next level is where you own the strategy for your product or a set of features within a large product. Typically, you are a senior product manager at this level, owning the roadmap along with your manager. The next level, usually a Principal Product Manager, is where your responsibility spans multiple product lines. You are responsible for arriving at a strategy for your product and have to convince cross-functional teams to work with you to help you succeed. The scope of problems at this level is more vague and complex, which can lead to questioning the fundamental user behaviors and system architecture. At this level, the PM is expected to foster collaboration across teams and bring clarity to their and dependent teams. Beyond the Principal PM level, PM jobs become extremely cross-functional and involve crafting the company’s overall product strategy and having a POV across the company, cutting across different business units. Finally, PMs at this level are expected to mentor junior PMs, give them direction based on the high-level strategy, and build executable 1-3-year roadmaps. 2) The management track: PMs at a Principal level in an IC track are usually at a Senior Manager level as a people manager. As a PM people manager, the role changes to mentoring PMs, helping PMs progress in their careers, and finally aligning with cross-functional leaders to ensure their team's success in large projects. PMs at director and higher levels also contribute to the overall company strategy and drive more future-looking initiatives.

I have worked with PMs who do not have an engineering or CS background but have worked in other functions in a Tech company, such as Project Management, Marketing, Sales, and Customer Success, to name a few. The underlying skills for these functions overlap with the PM job, such as requirements gathering, listening to customers, narrowing down their pain points, identifying the right target messaging and product positioning, etc. If your skills align better with one of the other functions, I would encourage entering one of the areas and switching to a PM function after a year or so. This way, you will have the advantage of knowing the customer, product, and teams before switching. The other route would be to consider your domain experience. E.g., I would target those companies if you are a legal or healthcare professional with rich domain experience.

The PM-Director role can differ from company to company. Based on my experience, at the Director level, one becomes a people manager managing an area of the business. I see a good Director of PM who understands the changing landscape and has a POV about how your company should navigate the change. So here are the top 3 skills I believe a PM should acquire to move to a Director level: 1. Consistently delivering results that positively impact many customers and iterating on them with a long-term vision. 2. Has east-west thinking, meaning understanding the value across product portfolio beyond what’s in your control 3. Influencing cross-functional groups to build futuristic capabilities that impact a large number of customers and helps position your company as a leader in the space Finally, find a sponsor, typically a senior executive, who can spot your vision as not only aligning with company goals but also bringing long-term benefits to the customer. Having allies at the executive level will help you position yourselves as a leader.