Here are some of the common mistakes I've seen (and done!) PMs make that results in not getting buy-in for your roadmap 1. Not aligning on the outcome explicitly - What is the outcome (Revenue?, better customer experience?, Faster time to market?) your are driving with your roadmap and is that clear to your stakeholder? Is your stakeholder aligned on this outcome? If they are not, then the buy-in for your roadmap means nothing because there will be misalignments on many decisions you will need to make as you execute your roadmap. 2. Not communicating the principles and constraints that drive prioritization of your roadmap - The factors that influence prioritization may not be obvious from just looking at the items on the roadmaps and the stakeholder may not have the same context as you do. So, what is obvious to you when looking at your roadmap, will not be obvious to them. 3. Giving the impression that your roadmap is not changeable - nothing frustrates a stakeholder more the feeling that they have no influence over your roadmap. You should give them a chance to have an input into your roadmap before your roadmap is finalized.

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.

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."

The job of PM relies on influence, not on ideas. As a young PM, I always suggest to focus on building influence small steps by small steps. Get small wins. People start to follow you because they see that you can achieve things, not because of your ideas. So as a PM start by achieving things, pick one thing and get it done in a short amount of time. And repeat it.

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.

* Ability to get up to speed on unfamiliar, complex areas quickly * Highly reflective on past experiences and deep growth mindset * Infectious curiosity about customers * Succinct communicators, verbal and written These are some of the most difficult qualities to coach, and become more difficult to coach the more years of experience the person has, in my experience.

I don't think there is a typical product career path! Many of the PMs I have worked with or hired have changed careers and moved around in different roles. I see people enter from college with software engineering backgrounds, or experienced senior people moving from other software crafts such as design, engineering and project management into product management. For example, I have former startup founders and former DevOps engineers on my current PM team. If there is something typical about all paths - it is that PMs are people who have interest and experience in technology and truly want to improve customer and user experiences with technology.

I have observed that the word strategy can be intimidating as well as misunderstood. In its simplest form, product strategy is a process of defining what your options are, and then selecting which option has the greatest chance of success. The most important step is getting REALLY clear on what your options are - which requires a deep factbase that includes market research, customer research, and product insights. The process that I use is a simple 4 step process that you can apply to most strategic decisions you need to make within a business: (1) Build your factbase (2) Define your options (3) Determine which option is best supported by the factbase (4) Make your decision & socialize. When I run this process at BILL, it usually takes between 6-12 weeks depending on the depth of factbase that we need. You should be spending the majority of your time working on your research so you can have a solid factbase as the foundation for data driven decision making. Here is an example approach you can apply to your own product strategy. * Kickoff: Hold a strategy kickoff so everyone knows you are starting the process - include key stakeholders and walk them through the scope of the strategy and the process you will use to develop it. Let everyone know how and when they can contribute or get updates during the process. * Key Questions: Build a list of your hypotheses and key questions to answer. This will help you understand what you need to learn with your factbase development. * Factbase Development: Start your factbase development. The depth of the factbase will depend on the scope of the strategy - I always include market research (market trends, TAM & SAM sizing, competitive analysis), customer research (both qualitative interviews and quantitative surveys - across current and prospective customers), product insights (this is only necessary if you already have a product live - it includes all your product analytics like conversion, activation, engagement, retention, known feedback, etc.) * Define Optionality: Once you are 50-75% through your factbase, start defining the options you see emerging. Your options should be distinctly different directions you could take. As defined, they should be mutually exclusive options, even if you do decide to take elements from each in your final decision. I usually do 4-5 options. Option definition should include: * 3 year look back vision - this can be a statement or visual of where that strategy lands you in 3 years * Target customer * Target “jobs to be done” * Core value prop for the customer * Business/market opportunity * Competitive advantage (why you have the right to win in the market) * Strategic focus areas (key things this strategy requires you build) * Select an Option: As you continue to finish your factbase, start mapping the research to the options that you have. As you finish your factbase, you should start seeing one option have more supporting evidence than the others. * Write up your Strategy & Socialize: Once you have selected which option you want to pursue, write up your case. Use your research as the supporting evidence to defend your strategy decision. Socialize with key stakeholders. 

Let me assume you are staying within your software (or hardware) realm, as switching from software to hardware product management (or vice versa) could be way steeper hill than entering a new domain like AR/VR. Here is something that would made me seriously consider a candidate without a specialized AR/VR experience - for an AR/VR position: * Stellar track record in non AR/VR product management. You rock as a product manager - many will consider this more valuable than hands-on with the domain. This is table stakes. You are already at disadvantage, so first of all demonstrate you are a rock star PM. * Story telling - if at all possible, find and demonstrate how aspects of your prior work can be applicable to AR/VR. Was there a project where you came up and succeeded with an unconventional UX solution? Tell a story how AR/VR is evolving quickly to find new UX patterns - and how you can apply your past experiences to that. * Domain knowledge: yes, you didn’t work as an AR/VR PM. But you surely invested a lot of time in understanding this domain. You know the market, the players, the product, the technologies. You’ve been to industry events and meet ups to hear inside stories first-hand. You talked to AR/VR customers about their experiences, yays and nays. You can speak the same language with your hiring team. * Passion - lack of hands-on experience is your disadvantage. Make your genuine passion offset that one. Show it’s not “just a job” for you. With all other things equal, this will tip the scale in your favor.

* the ability to ask questions and synthesize - customers often tell you what they want to see happen in the product, but that may not be the most scalable solution for all of your target customers in aggregate. In customers interviews, get to the root of the “why” behind feature requests - why are they asking for this? what problem is it looking to solve? how big of a problem is this? what workaround are they doing today to bypass this problem? how would solving this problem help your customers better reach their goals? how would solving this problem make your customers more productive overall? * the ability to prioritize and say no - “It's not prioritization until it hurts” - Ami Vora, CPO of Faire. Good PMs collect more customer problems than their engineering team is able to solve. Great PMs are able to diplomatically say no to the majority of the problems being asked for a solution. They also able to do this while keeping customers/stakeholders understanding why choosing to prioritize certain things over others. And it’s supposed to hurt a little bit. * curiosity and insatiable appetite to learn - it would definitely help if the PM innately had high raw intellectual horsepower, but that will get you nowhere if you’re not constantly willing to adjust, learn, and adapt - every customer, product, company, org, stakeholder, is different. There’s no shortage of techniques and tools to learn if you want drive your PM skills forward, from learning SQL, knowing how to run effective user research, get great at conducting competitive analyses, it’s etc..