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.

Great question. It's really hard to prioritize small, iterative product improvements against large new features/bets. In my experience you need both, as well as a few other aspects. The way we do it in my teams is to think of it as balancing investment levels between different buckets, and to dedicate capacity to each of these buckets. Otherwise it's a constant struggle. We've tried to describe it in this section of the Atlassian product discovery handbook talking about ideas, and that one about prioritization. A couple of different types of buckets: * Boulders, rocks and pebbles * Boulders: large investments with potentially big payoff but high uncertainty, too. E.g. one or multiple teams over one or multiple quarters. * Rocks: medium sized investments with fewer risks, but potential for delighting users. E.g. one team for a month. * Pebbles: Small, typically straightforward change. E.g. one person for a week. * Don't underestimate the impact of rocks and pebbles! In my experience users LOVE to see the app they use get better every time, that's a great way to create fans. * RUF: Reliability + Usability improvements + new Features. Think of the RUF framework as a pyramid: * At the base of the pyramid there's Reliability. Reliability is about building trust. Trust takes a long time to build, but can be destroyed very quickly — a single event of data loss or security breach can be a serious source of churn, let alone repeat incidents. So you need to invest in your product's reliability first and foremost. * Usability Improvements comes second: a feature is rarely “done” — it’s part of a system and that system needs constant tuning. In your roadmap, it is important to allocate budget and resources to keep investing in improving your current feature set. * At the top of the pyramid is new features, both large and small. Then you decide how you want to invest in each: E.g. for a super early stage app you might be spending all your time on boulders and rocks, and little in reliability or usability improvements. For a more mature product you might spend 50% in the reliability bucket and only 10-20% on new features. Then how you actually implement that in your team can vary. In my teams we look at it at investment over time: we might be focusing on a boulder for a quarter, then go back and tackle a few rocks and pebbles. Some of the teams have a rotation where 1 engineer is focusing on pebbles each week. etc. But the important part is to have a strategy and make it a conscious choice, vs something that you react to every time you get a new request from a customer or stakeholder.

I currently work in the intersection of enterprise security & AI and it is incredible to see the use cases that have emerged for AI in this space. * User research: As I mentioned in one of the earlier questions, AI tools can be a fantastic source to understand user trends, market, and competitive trends. For example, you can take a look at online user reviews for your product to understand key functionalities and usability gaps. * Product functionality: Within security SaaS we often use the framework of detect, investigate, and resolve. AI is changing each of these experiences from a product development perspective. For example within ‘detect’ AI is enabling us to develop product experiences which help organizations more proactively understand attacks their orgs are more vulnerable to. Leveraging machine learning and external data sources we can provide scores to attacks to help understand how significant a vulnerability truly is. Within remediation AI helps to develop automated playbooks based on other similar playbooks that can help users more quickly resolve issues and get external data about how other orgs are resolving the issue. * AI experiences: In addition to augmenting the security workflow to make it more productive and effective, gen AI is also enabling us to create net new experiences for prospects and customers. For example if an organization doesn’t have the security skillset to complete one of the tasks across detect/investigate/resolve - what is the role AI could play here in filling the gap? How can AI be leveraged to empower shift left security in an organization so that developers are encouraged to incorporate security from the get go in their designs? There is so much potential for how AI can fundamentally change the product development process and excited to see all the innovation organizations bring to their products over the next two years.

If your org is driving significant benefit from a leadership position in the market -- whether that's a brand that drives an acquisition funnel, operating efficiency from scale or something else, it's reasonable to think about how to maintain that lead. * Consider carefully why you are in a leadership position versus other customer options (competitors, substitute products etc). Is it unique? Sustainable? Are there small firms that could steal share by, for example, providing a more specialised or concierge solution? Or is there a large firm which could extend into your space, with advantages (like access to funding and time) that you don't have? * Market leaders, especially large ones, are exposed to the innovator's dilemma. Should you invest in areas that could, if successful, cannibalise your larger business before anyone else does -- protecting your position?

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.

Using a clear, published framework that aligns to the organizations broader goals or strategy is important to prioritizing any set of work. Without this, it will be difficult to build confidence with your team that decisions will hold up and they won’t have the context required to make sound decisions in their execution of the tasks they are assigned. A prioritization framework doesn’t need to be complicated - in fact its often better if its so simple that it can be committed to memory. In many cases the best discussions I’ve had with my leaders focus on aligning on the prioritization framework over a whiteboard, with the output often being a simple bullet list or table calling out the characteristics of projects that will fall into each bucket. It’s also advisable to test your prioritization framework by running a few examples of actual work items and seeing if the team leads align on how the framework is applied and the priority outcomes for each. Setting the framework is usually simplistic when running a small team with clear goals or OKRs, as those can easily map directly to the priority framework you define for the team. As you take on more strategic roles where there are difficult calls to make balancing resources across competing priorities, I’ve found that the “Core Context” model by Geoffrey Moore helps me form my first cut at a priority framework for delivering on that strategy. 

PMs are able to help engineers with: * talking to all different types of customers and prospects, so that we constantly have informed/holistic insights into most impactful problems we should be solving for our target customer * taking the set of problems we have to solve, strategically sequencing them (roadmap), and pitching this to leaders internally to ensure buy-in + resources to fund this work * take the lead on solutioning - working with engineering, product design, content design, user research, and data science - to ensure that we are building a feasible/impactful solution for the right problem * evangelising the products that we are building and collaborating with GTM stakeholders (Customer Success, Account Executives, Solutions Consultations), pricing teams, business development, legal, product marketing - so that the product is not only built, but well-loved and highly adopted by our customers * and so many more things Engineering leaders could drive all of that, and they are capable to. But oftentimes they are focused on managing large organizations of engineering staff and driving technical/architectural vision. And good PMs have years of experience and training on this work specifically, as opposed to having to focus on people management.

1. I like to start with the product stage, context, and strategy. From these, and your customer data you should be able to determine your priorities * With an early stage, pre-PMF product, you may be prioritizing learning about your customer needs and how well your product is meeting those needs above all else. * When you know your product is meeting some people’s needs or providing some valued entertainment, you can focus primarily on increasing engagement and retention. How can you make your product better in ways that result in longer user sessions, more repeated user sessions? * When your retention curves look good for 30+ days (and ideally 90+ days), it may be time to focus more on growth. 2. You may have a more complex product though. E.g. one with a creator or developer or seller ecosystem and a 2-sided marketplace dynamic. * In these cases, you should be aligned on a strategy that includes sequencing (e.g. how are you getting high quality content to begin with in order to engage consumers? Or, how can you increase awareness and users enough to become an attractive marketplace for producers?) 3. Funnels also make great lenses. * New user acquisition (by channel and campaign, and the UX flow for each) * Retention over time * Conversion or upsell funnels * Social growth (if any) 4. Things like speed of learning, speed of improvement, and iteration velocity also matter to winning in the long run. So you may need to think this through as well. * Example: Is your tech debt getting so high that you’re wasting a ton of time dealing with regressions? Is this driving customers away or leading to low review scores?

Many data-driven Product Management (PM) teams often overlook long-term strategic KPIs, such as Customer Lifetime Value (CLV), by focusing on short-term metrics like quarterly margins or one-off transactions. This approach can be detrimental, as retaining customers typically yields higher CLV and reduces churn-related costs. Another critical KPI often missed is Feature Discoverability and Time to Value. Despite having sophisticated features, users rarely utilize them due to: Difficulty Finding Features: Users struggle to locate necessary features. Longer Time to Realize Value: Understanding and realizing the benefits of these features often takes longer than competing alternatives. By prioritizing these long-term strategic KPIs, product teams can enhance adoption rates, accelerate customer value realization, and ultimately drive sustainable growth and customer loyalty.

The two things you need to ensure that you can get your exec team on board with your strategy is (1) Clear communications plan (2) A strong, well researched factbase standing behind your strategy. (1) For clear communications: Start your communications plans early! I bring my exec team in at the very beginning of the product strategy creation process. I hold a product strategy kickoff event to let everyone know we are embarking on a product strategy exercise. I share the timeline for completion, the process we will use, and the milestones where we will update the exec team on the progress and give them a chance to weigh in. During the development of the strategy I usually do 3 exec check-ins: (1) Kickoff, (2) Review the research and options, (3) Review the product strategy recommendation/decision. I usually hold these each about 1 month apart to keep people engaged and the momentum high. Before the final meeting on the strategy recommendation/decision. I often do 1:1s with key stakeholders to familiarize them with the research and recommendations so that they are already aligned before we go to a larger alignment meeting. (2) Your product strategy process should always include the development of a factbase. The factbase helps you build your case for the strategic option you are selecting. Having a deep, well researched factbase ensures that you not only developed a data backed strategy, but also drives the believability of your strategy. It is key to include 3-5 data points when initially communicating your product strategy recommendation. This can help to drive alignment with your strategy via facts, vs. arguing with execs over opinions. Always come back to the research.