A super common question! Traditionally the term "product manager" can often mean different things depending on the size of the company, the product's stage, and sometimes the overall market segment. I often times bucket them into these core groups: 1. Technical Product Managers (TPM): These PMs work closely with engineering teams on more technical products, thinks like API driven products where the end "customer" is technical in nature. For these roles, you will need a deeper level of technical expertise and the ability to understand the technical aspects of your customers needs. 2. B2C (Business to Consumer) Product Managers: In a consumer-facing environment—like mobile apps, e-commerce platforms, media consumption products — I find that PMs often emphasize UX and product design (along with core PM responsibilities). One of the key areas that this group focuses on is leveraging a typically broader/larger customer base to do things like A/B testing, and quick iteration on product designs to validate assumptions and feature value. 3. B2B (Business to Business) Enterprise Product Managers: These enterprise PMs focus on delivering products that solve businesses' complex problems. I spent a lot of my career here and this type of PM spends a lot of time on sales enablement, strategic account engagement, and roadmap management. Given that most B2B solutions have a longer sales cycle, their relationship with sales is key to success. Depending on the size of the organization, this type of PM also focuses a lot on the financial side of the product. 4. Infrastructure Product Managers: These PMs (sometimes internally facing only) focus on building components that other teams and products rely on, oftentimes within an organization. For them, the GTM isn't as relevant but they need to understand and balance things like scale, interoperability, and business alignment. Figuring Out Your Best Fit: 1. What are your Interests: Consider things like Do you enjoy getting into the weeds on technical discussions? Do you more get energized by user research and design? Do you geek out over analytical data and love looking at usage metrics to drive feature development? Each type of role has a different focus, so find the things that excite you. 2. Consider the Environment Do you want to reach a huge market of customers and iterate on minor feature developments and enhancements? Or do you want to work closely with larger business customers and develop a deeper understanding of their problems and how your product can evolve to meet those specific needs? No right or wrong answer, just what gets you pumped up each day. Remember, it’s about aligning your career desires, your core strengths, and the types of challenges that get you fired up to solve each day. We are problem solvers, so what types of problems do you love solving and how do you like solving them? Many PMs start in one area and end up in another. All the roles share a common framework of ensuring we are delivering business value for our organization and delighting our customers with innovative and useful solutions to problems they either have or don't even realize they have yet.

At every level, the core PM competencies of driving clarity and alignment through clear communication, delivering measurable outcomes for the business and influencing without authority remain the same. But the ambiguity within you are required to clarity, the impact of the outcomes you drive and the seniority of the stakeholders you influence increase as you become more senior. If your are a people manager, the size of the PM team, and the diversity of PM roles within the team, increases as you become more senior and you will need to start thinking about strategies to grow and retain talent at scale. In a nutshell, it's the same core competencies, but you are expected to operate with greater ambiguity, deliver greater impact and have broader influence commensurate to your seniority.

This is somehow the simplest and toughest question on here 🙂 Your typical PM career path can look like: * PM: Responsible for a KPI or set of features * Senior PM: Responsible for a product area end-to-end * Staff/Group PM: Responsible for a product end-to-end * Principal/Director PM: Responsible for a business unit * VP PM: Responsible for multiple business units * CPO: Responsible for the entire Product org ...but I personally don't find that framing helpful because it varies so much from company-to-company and there are many factors that would make me hire a Senior PM at company over a Director at company . So, here's an alternative approach to thinking about a PM career where each stage could span across multiple titles depending on the maturity of the org: * Deliver at a high velocity: Ship! Ship! Ship! Build the muscle to take things from idea to product and do this at an insanely fast pace. * Learn to love the craft: Now that you've built the delivery muscle, master the details of your craft. Assess other products through a keen eye and try to discern what differentiates a good product from a great one. Learn to care about the details, since it's as important as the high velocity. * Be a driver for your product: Go beyond your feature or product area and think about the entire product. Familiarize yourself with the P&L, revenue drivers, GTM motion, and try and identify opportunities to improve customer value and ARR for your product line. * Be a driver for the business: Do ^ but across products for the entire business. This also involves identifying opportunities for new P&L lines through product innovation.

Product Manager position could be optional. A team building a software product will have someone fulfilling a product manager role either way. * Who will take accountability for the market success of team’s work? * Who will deeply understand the market, the customer and their pain worth solving? * Who will fight for the team inside of the organization to acquire needed resources and to defend existing? * Who will be a “PR manager” building team’s brand inside of the organization? * Who will detect early learning and make a case for adjustments and improvements? This list may go on and on. Try to make the case not for the position of a PM (“I am a PM, you listen to me”), but for the inevitability of the work above for any successful team. Chances are, your engineering leader and their team do not find this type of work most exciting. Hopefully they are reasonable to agree it is required, or at least helpful for the eventual market success of your product. From there, if you established there is work to be done - demonstrate how you can take this work off the team’s plate and have them focus on what they do best and enjoy most - building great software (or hardware, if that’s your thing).

I like 2 use 2 things to evaluate a job: I should either learn a lot, or earn a lot (or ideally both!). We try to always favor learning, but sometimes your familial situation makes that earning may become the main criteria at some moment in your life. Overall, your career is not the most important, your life is. Nothing beats feeling good in your life, and this is what you should look for. I don't think there is any way to measure when it's time to leave, but usually you know it. Deep in you, you hear this little music telling you "it's time". And when you hear it, just look for other opportunities.

When you receive critical feedback that you don't fully agree with or don't know how to act on, it can be challenging and discouraging. For feedback to be effective, I find it needs to be timely and based on examples. It can be helpful to have a conversation with your boss about working styles and preferences around giving and receiving feedback. You might suggest: * Timely feedback: Requesting that feedback be given closer to the event (e.g., after a meeting or presentation) so you can act on it more effectively. * Concrete examples: Asking for specific examples of where you could improve, especially when themes or patterns emerge in the feedback. This helps ensure the feedback is actionable. * Written feedback plan: Suggesting a written development plan to ensure both of you are clear on what needs to be addressed and how you’ll work on it. * Requesting positive & improvement feedback: Important in feedback is to have a kind and respectful relationship. Often it is good to call out to your manager how positive feedback helps you do your job better and this can also help provide a more balanced view. This can help you and your boss understand each other’s communication style better and make the feedback process more productive. It also gives you a chance to reflect on whether the feedback is valid or if you need to discuss your perspective more clearly. If you still don’t agree with the feedback you can push back with examples of why you see things differently. The book Radical Candor has some great tips on this topic.

Setting a fast-paced rhythm and providing predictable touch points are the two practices that a product manager can heavily influence that can impact team velocity. These two concepts are related: a rhythm gives teams in your organization a common pattern they can align to. Everyone knowing that the team operates on sprints of the same length, with a common calendar, how decisions are made and communicated in a common way, a clear way drivers, approvers, and contributors are determined and documented for projects - all feed into a sense of rhythm and predictability. I call out predictable touchpoints specifically because they provide some level of control on the thrashing that organization leadership can inadvertently cause when interfacing with the team. By setting the touchpoints at the various levels of leadership in advance, and providing clarity on what will be reviewed and decided at each touchpoint, its easier for the product manager to isolate which areas of the team may experience change and keep other teams more focused. Lastly, it's important to work with your engineering and design counterparts to keep a constant investment in agility operations and tools. The faster each discipline can do their daily tasks, the more agile the overall team will be. This can range from providing time for developers to adopt AI code generation tools, optimizing a CI/CD pipeline, resolve long-standing operations issues that are costing time, and so on.

* in product reviews, when an exec/lead asks you something about your product decision, don’t table it and say “idk, we’ll assess and circle back with you in xx days”, rather just say what you think ought/should happen. You could state that these are assumptions and you could/should validate later. But as a PM, you’re paid to have an opinion on the spot, and oftentimes we don’t have all the data/research at our fingertips. At least the exec could course correct you on the spot in case you need misdirection, so you don’t fall into a rabbit hole * in presos to execs, lead with the spicy thing first (the solution, the recommendation, etc..) and have the justification/rationale/analysis follow it. for non-exec presos, it’s generally recommended to reverse the order. This may be obvious, but I’ve seen it overlooked sometimes. * expose a healthy dose of skepticism, call out product/market risks/assumptions - but do it in the latter half of the preso, If you only present positive info, folks naturally get suspicious around what are you hiding (this was inspired by Mihika Kapoor's talk at Lenny's Summit earlier this year, but it's principles I've adhered to and shared with my PMs for the past couple years)

It sounds like you're potentially looping your designer in too late. They should be there early to help you think through competitors, potential inspiration in the market, and help you learn from users. Getting a user's first explanation of their painpoints is one thing, but you will develop your understanding of their painpoints by showing them potential solutions (that you and your designer work on together). That all said, if I'm short of immediate inspiration, I like to look laterally, outside my immediate product space, for inspiration. For example, when I was working on how to make individual work rewarding in Asana, I looked at how fitness apps help users feel a sense of reward and achievement. If something works in another use case, there's likely something you can learn from and adapt to your use case.

There are two ways to think about what the right KPIs are for your product and product team. One is to use a general model of customer lifecycle and the other is to align closely with your company’s overall goals and north star metrics. For the general customer lifecycle framework, a good place to start is defining metrics for each lifecycle category: discovery, acquisition, activation, engagement, retention, revenue (if applicable). Now not every product has every category, but this will get you a good place to start. This framework works for internal and platform teams as well - I know since I use it with our platform teams at BILL. While you can start with this lifecycle framework, you will want to make sure to align to the company’s core KPIs. You will want to make sure any metrics that you select within the customer lifecycle framework roll up well to the overall metrics the company is trying to move. This will help ensure that all of the metrics you are monitoring are aligned with the company direction. I will also call out that defining the right KPIs to understand and monitor day-to-day is not the same as setting goals. KPIs are intended to help you understand how your product is performing overall. Goals / OKRs are your commitments to specific ones that you want to move or change. So defining KPIs are a very important first step to get visibility into product performance, then you can get a clearer picture of where you want to focus your roadmap to make meaningful changes.