The transition from a Sr Product Manager role to a director level usually focuses on developing your strategic thinking, influencing others across the organization, and guiding larger portfolio decisions. In other words, you’ll need to grow from an execution-based mindset to that of one centered on longer-term vision, team leadership, and effective decision-making (at scale). In my experience, these are the key areas that one should focus on. Skill Sets to Develop: 1. Strategic Vision & Storytelling: Climbing up the ladder isn’t just about managing more product roadmaps; it’s about defining the strategy and market direction, gaining a deeper understanding of the business strategy and how it relates to long-term execution plans and anticipating future market needs. A key bit of being at a higher level of telling that story and connecting those dots for others. Be good at explaining what the strategy is and why it's the right path for your organization. If you can't bring people along the journey, you will never get their full support. 2. Stakeholder Management: The higher you go, the more internal and external stakeholder management you will have. In lower levels that's more at a feature level management, but at a Director level, it's more about strategy implications and trade-offs with your stakeholders. 3. Leadership & Talent Development: Typically at the Director level or above is managing a team of Product Managers. For me, I have been managing Product Mgrs for nearly a decade and find it one of the most rewarding parts of the role. Growing a team of strong product thinkers and empowering them to execute efficiently is a huge part of moving up that corporate ladder. 4. Process Process Process As you move up, you need to ensure your team has the tools and processes in place to support them. You are less in the weeds each day and thus have to ensure that you have enabled them with a framework to follow that will make them successful in their careers and drive your product forward. However, I despise process for the sake of process (a common issue at larger organizations). Be willing to challenge a process that isn't adding value and ensure that what you drive provides your team the room to grow. I like to think of it as guardrails for my team. I don't tell them specifically what to do and a playbook/process to follow letter by letter. I provide them with guidance and point them down the right path with some guardrails to ensure they don't make a left when they should be going right. While I drive the overall process, I always remember that "just cause it wasn't done exactly how I would do it doesn't mean it wasn't done right."

PM work life is a firehose of Slack/Teams message, customer emails, meeting requests and deadlines. Here is what I find helpful to make sense of the chaos and stay on top of the key things. * Capture, Organize, Get Shit Done. Resist the urge to jump on every message or email the same moment - you may find yourself exhausted while still behind on your goals. Instead, find a tool which lets you to quickly “capture” a thing which require your attention - and move on. Organize these to-dos thoughtfully - later, when you have time: what need to be done now, today, later this week? Some people find Eisenhower matrix framework helpful, though it may require much discipline and self-training to apply it to every day situations. My personal go-to solution for capturing and organizing PM to-dos is Trello. * Meetings. Look at your calendar and brutally question it. Which meetings you don’t have to be in? Which ones you’d be fine just reading a summary after? Sometimes you’ll have to say “no” to get your work done, even if it slightly annoys someone. * Async collaboration. A great way to reduce meetings load for me is Atlassian Loom: record a short video clip and share with your collaborators, let them responds or even with another video clip, async, at the time which works best for everyone! * Focus time. Every week you likely have a Big Rock - a bit of work which isn’t immediately urgent, yet have an outsize importance and require significant focus time to accomplish. * Plan your week. Apply everything above to your Friday routine - plan your next week ahead. Meetings you’ll decline? Focus time you’ll block on your calendar - to accomplish most important tasks? 3 things (maximum) you are looking to accomplish next week? * Plan your energy, not time. Lastly, recognize when you are at the peak of your productivity - late afternoon? mid-day? morning? Do your best to allocate this time to the most important things you are looking to accomplish. You are most productive on Fridays? Make it a no-meeting day to finish up that blog or product spec!

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

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.

I don't really have a "scientific" answer to this - I've always done this in 2 ways: creating a bottom-up model, and trying to find data from other companies/competitors to benchmark against. Bottom-up model I've usually done this in a giant spreadsheet, trying to build a model with a lot of documented assumptions. Here's how we did it for Jira Product Discovery: * First, decide on how we would package and price the product, which we did via conversations with our early lighthouse customers, a survey, etc. We landed on: per user pricing, some users pay, some users don't, at a price of $10/user to promote collaboration use cases (we didn't want the price per user to be a blocking point to invite more people to collaborate). I'm not an expert at this but I highly recommend this conversation between Lenny and Madhavan Ramanujam on "the art and science of pricing" * Then, estimate how much revenue, based on that, we could get from the current customer base in the beta. We ran a beta for about 18 months and had > 1000 companies using the product for free. We made assumptions about how many of them would buy the product based on their usage of the product and what we knew about them from our other products (e.g. if they're already paying for Jira, if they're paying for more than one product, etc.). We already knew how many users they had on Jira Product Discovery, so with a price of $10/user we were able to estimate initial revenue in the months following general availability * After that we estimated sign-ups and conversions. * For that we used the data we had from sign-ups and conversions from the beta, we adjusted it (because beta was free), and we compared with sign-up and conversion rates from other products at Atlassian - some were a good benchmark (early products), some were not (more mature products). * We also estimated the impact of experiments we would run to try and recommend the product to existing users of Jira. We knew this was going to be our main distribution strategy, which we had validated via a few experiments already, so we had some data to work with. * Based on this we came up with a guesstimation of signups / month, conversion rates from trial to free/paid (which would go down in time as we reach more customers who are not early adopters), we took into account an element of churn, we estimated the number of users per customer (based on beta users, and also assuming we'd progressively reach bigger companies), etc. * We added to the model future initiatives that could impact revenue - for example the launch of a Premium plan at a higher price point. * Etc. - basically we built a bottom-up estimation based on everything we knew (data) but also bets into the future (new features that make the product appealing to more customers, new plans) The model is usually wrong at the beginning, but it does get better over time as real data comes in. Benchmark with competitors At the very beginning of the product, before we even wrote a single line of code, we tried to assess the TAM/SAM/SOM. There's a lot of literature online about how you do that. What I found works best for me is to assess this by proxy, by looking at other players in the market/competitors. You can find a great deal about a company by crawling its blog, finding out who is in charge, look for talks they gave, opinions they give online, etc. There is so much information online. For example: a competitor might claim they have X users, and you can match that to their pricing structure (public information) and estimate their ARR (Annual Recurring Revenue). They might boast on a podcast that they have 80% growth in the past year - that gives you an idea of their momentum. Do that for a few companies and it gives you an idea of the current size of the pie and how big the pie is growing. And you can decide how big of a slice of that pie you want/need in 1-3-5 years for this to be worth it. Careful though: another company making $100M ARR is not a guarantee it will be the same for you: it also depends on your business model, pricing and packaging. -------------------------------------------------------------------------------- By using a combination of these 2 approaches (bottom-up, top-down) you can usually get to a decent answer. But remember all this is bullshit up until the moment where customers take out their credit card! So make sure to find ways to keep testing your prospects' willingness to pay from very early days.

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?

1. Executive sponsors – if your org leaders don’t think PLG is a priority, it’s not happening. Period. 2. Effective structure – Every growth PM on the team needs to have the right balance of focus (depth) and scope (breadth) 3. Functioning ecosystem – The more intuitive the AB testing and analytics platforms are, the more seamless the operations of your growth team is. The more you invest in the squad – engineers, data science, design, PMs, operations – the more effective the outcome/impact is.

I've been working at fully (or practically) remote companies for ~5 years now and I believe they can certainly work. Tools like Zoom, Slack, and Miro can (mostly) handle the day to day activities of product teams. However, in person time is still critical for some activities and for building a product culture you want. Some rules I have: 1. I try to do a team offsite at least quarterly. This allows for free flowing discussions and brainstorming that don't translate well virtually. I plan a few days that include ample whiteboard time as well as dinners to do some bonding. 2. As a product leader, you need to be hyper aware of how team members perform in a virtual environment. You don't get as much signal from body language virtually. I always try to check in during 1:1s on how each team member feels about the culture, their role within the team and try to manage virtual meetings accordingly.

* get some quick wins under your belt: * shepherd a small product/feature/enhancement that’s currently in development out to market launch * jump into user research calls to understand customer pain * jump into sales calls (prospects or existing customers) to understand pain * work with user research (or do it yourself) to understand and document the nature of different customer personas/segments, if this hasn’t been done already * write a PRD for small product/feature/enhancement, get feedback on it, and refine accordingly * learn * know the high-level product metrics that the team is currently tracking, and where they generally stand * immediately start using the product putting yourself in the shoes of a new user, and jot down anything that could be improved and what friction/problems/pain you’re facing * learn as much about the existing products in your ownership/purview/domain as quickly as you can * learn about other products at a cursory/introductory level so that you could see where your product fits in the grand scheme of things * build relationships * form and maintain strong relationships with other product development stakeholders all across the board, starting with your developers, designer, research, analyst, marketer, and manager

Thank you for your question. A lot of this comes down to the expectation of your organization for your role, but at a high level, product management roles can be seen to consist of three main areas of focus: strategic (e.g., determining how you will win in the market and the path to get there), operational (e.g., the processes and determination of how you will execute to meet current goals and achieve strategic plans), and tactical (e.g., doing discovery and writing requirements to build product). Generally junior roles (e.g., associate product manager) will consist primarily of more tactical, with a small focus on operational and strategic activities. As you progress to more senior roles, (e.g., to principal product manager, director, and beyond) you will see the focus on tactical reducing, and expectations of more operational and strategic increase. One of the biggest challenges I see in technically focused product managers who get into or seek more mid-level product management roles is the switch to becoming more strategic, where typically they also need to gain more commercial focus and understand the overall market and go-to-market requirements to see their product succeed. At this level, stakeholder engagement and management start to become even more important. For example, when selling a product that is sold to external customers, it’s imperative to work with sales and partner teams, marketing, finance, and potentially other functions so that you can get buy in and engagement to see your product or feature successfully sold. Getting into senior level product management roles switches focus even more, as then you’re looked to lead the product management organization, which may include taking on other functions (e.g., product marketing and user experience teams), setting the vision for your organization, driving and developing your team to ensure they can achieve that vision, and more. What I’ve presented above are generalities, but it’s important to note that different organizations can have wildly different expectations of product management. You can see that in the many different job descriptions and expectations for a role you may be applying for, or that you may find yourself in. It’s important therefore to understand the expectations of the role you are in or are seeking to get into, and work with your manager (or undertake in your own time) to identify and follow through on opportunities for development to strengthen areas that need more focus. In that sense, seeking a mentor inside or outside of your organization, or even joining a community, can really help get a broader perspective and get input from more who have gone through a journey like your own.