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.

There are multiple things you need to get right before you start building a product, because the most likely outcome of creating one is that it will fail. To see an example of this you can watch this talk for how we did problem and solution discovery when creating Jira Product Discovery * Validating the problem space is important. For that I think the recipe is pretty straightforward: talk to customers and prospects and let them guide you. It's quite important to go in there open minded about what you're going to learn - because there's a high chance that all the assumptions you made when going into these conversations are wrong, that people don't face the problems you thought they faced, or not with the intensity that you imagined. I'd recommend getting coaching from a user researcher on interview techniques - otherwise you can easily meet with 50 customers and learn nothing. It's one of the most important skills for PMs (and humans are naturally pretty shit at this so it REALLY takes coaching). * You want to land on problems that are felt very strongly and urgently by the people you talk to, and are pervasive. * By doing all this you'll form a view on who your target customer is - you want to keep refining this. And you'll identify potential customers you'll want to work with to shape the solution. We call them "lighthouse users" and it's who you would want to build the solution for: they feel the problem strongly, are crafty and have tried many different solutions to solve them to no avail, they're great communicators, easy to collaborate with and have urgency in solving the problem. Find them, and the rest of the journey will be much easier! Read this post to learn more about lighthouse users. * But on its own it's not enough, there are other aspects to tease out. * You want to be clear on if there is a market - check out which companies play there, try to get a feel for their revenue and growth (there's a lot you can glean about that online); if you can, try to chat with investors who gave them money; understand the maturity of this market (early adopters, early/late majority, etc.). * You want to have a thesis for how you can win - e.g. do you have a distribution advantage, access to tech that's hard to reproduce, other? Note that the best product doesn't necessarily win distribution is going to be key to answering this question. * Distribution is super important and what will make or break your product. It's a good idea to validate demand and your ability to reach potential customers. In the past I've done this by creating and advertising a landing page on a website stating the problems and asking people to join a waitlist. That's how we knew we were onto something in the early days of Jira Product Discovery - within 3 weeks we had 3000 people on the waitlist (which contained zero information about the solution). * You need to have a clear answer on "why now?" - the problem needs to be felt really strongly and urgently by customers, maybe there is new tech opening new possibilities, maybe it's the right moment for your company to invest because of strategic reasons, etc. But you need to be clear on why this needs to happen now vs next year. * If you're in a bigger company with cash at hand, assess build/buy/partner opportunities - before jumping straight to creating something a new product: is there another company you could buy instead of building, and fast track everything by a couple of years? * Even after answering all this I wouldn't jump straight into asking for engineers. I'd only do that if we're not clear the solution is feasible, e.g. if it requires new tech that we don't master. After problem discovery, don't skip solution discovery! There's a lot you can/should validate without writing code: * In the past I've shown people slides with value propositions and asked them to explain back to me how the solution would help them. There's a lot I learnt by doing that! * Create prototypes, in Figma, or live prototypes than people can play with. You can gauge the reaction of the people you give them to: if they "just" look enthusiastic about the solution you can throw it away. If they're straightaway asking you if they can please please please start using it tomorrow then you know you're onto something * Even if you ask for an engineering team: start with technical spikes and prototypes, the goal is to validate the solution solves the problem and is feasible. All of this will also help you refine your understanding of the problem space (problem <> solution work hand in hand) You can also read more about it in the Atlassian Product Discovery handbook, that we wrote to help with things like this. Check out the "Ideas" section.

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

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

Great question. In my personal career journey as well as several hires I’ve made I’ve always found it helpful to try the new role before you go all in. When I was at a startup where we didn’t have well defined programs like Google’s 20% program or PM rotations, I asked to work with the PM team for 6 months on the side where I took on some of the PM responsibilities for a non-critical product. By doing so, I personally got conviction if the role was right for me and the PM team also got to see me in action. This made my transition much easier and also helped me come in at a more senior role. Similarly I’ve made hires who had a similar path - they often either did a 20% project or a full time rotation - and this helped make a case for their PM transition. If your organization doesn’t have formal programs to try the PM career path I’d encourage you to network with PM leads you are close to and see if such a project could be developed.

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. 

Making any discussion data driven helps drive meaningful outcomes. Start with understanding why a different team thinks they own the decision, which helps with your conversation. Given decisions lead to outcomes and hence impact KPIs, leveraging that correlation helps with alignment. Clarifying who owns the KPI, which is impacted by the decision helps identify ownership quickly. Once alignment is reached, always make sure to capture the decision/engagement model as a written artifact for future reference.

I've seen this situation quite a bit and the single most effective way to drive change towards impact-based product building is bringing data to show the downsides of the current approach. I personally failed to drive change early in my career because I tried to debate the merits of different approaches without bringing evidence (only theory). Even if you are to operating in a project-focused way, there are things you can do to shine a light on a better way: * Measure the impact of everything you are building (or being asked to build) - nothing drives change like showing investments aren't delivering impact. Go back and see how many customers are using features you built last quarter. Get that data in front of leadership. Include ways you could improve the approach next time (e.g. if we spoke with 3 customers before building, we would have known X would have been a better solution). * Get close to customers - this may be easy or hard to do in your organization, but figure out how to do it anyway. Ask for forgiveness, not permission. I like a situation where you are on a text-friendly basis with a few customers. This allows you to proactively get feedback before execution and offer this as evidence you may need to make changes. Make sure you don't let your bias get in the way here - also call out when what you are being asked to execute resonates with customers (let leaders know you are objective). * Find leaders who knows your current situation needs to change - there are usually at least a couple empathetic leaders in any organization that see the need for change. This may be outside of the product organization - it could be a sales leader, someone from marketing, customer success, etc. Work with them to first highlight the problem with project-focused operation and show a better path. Advice may differ slightly depending on your specific situation. A few situations I've seen where this is common: * In organizations where the culture is more execution than product focused (typically legacy businesses) * In organizations where leaders are making all product decisions * In specific parts of the org where a single leader is unable to let go of the details A few books you might read - Escaping the Build Trap by Melissa Perri, Transformed by Marty Cagan, and Aligned by Bruce McCarthy and Melissa Appel.

While this is not meant to be an exhaustive list, here are some aspects of experience and skillset that fall between table stakes and highly desired category: 1. Good presentation and communication skills 2. Self driven individual 3. Leadership skills 4. Examples of making an impact on the business, overall business acumen 5. Examples of decision making and rationale of making those decisions 6. Critical and logical thinking ability 7. Grit and resiliency 8. Domain knowledge 9. Examples of stakeholder management and execution track record 10. Self awareness and approach to handling failure/setbacks

True OKRs should be cross-functional and not limited to specific areas such as Product Management, Design, UX, or SRE. The "Objective" (O) in OKRs should promote alignment across teams, helping to avoid local optimizations. Key Results (KRs) can be function-specific and have asynchronous relationships with KRs from other functions. If functional OKRs are necessary, ensure that objectives remain aligned across functions. Regardless of the logistics of OKR training, Product Management can leverage OKRs to maintain alignment among cross-functional teams throughout the product lifecycle and foster a data-driven product culture. Tactical Production Objectives OKRs * Improve user experience by X%. * Increase monthly active users (MAU) and weekly active users (WAU). * Enhance performance by Y%. * Achieve scalability improvements by a specified number. * Drive revenue growth by Z%. * Strategic Innovation and collaboration OKRs * Dedicate X% of time to user research * Improve Net Promoter Score (NPS) by Y%. * Increase funnel conversion and productivity by Z% through collaboration between Product and Sales teams.