I will share first two steps that I follow. Step 1: Is this problem worth solving? 1.1 Problem definition and user segmentation * B2B product: A business customer must have a genuine painpoint that they are willing to pay for. Some problems are not big enough problems, hence not high priorirty for the business users, these are not worth pursuing. Fine tune the problems till they hit * B>B>C: The business user/stakeholder may have rightly identified a problem but may not have the best ideas in terms of what solutions can work. Validate the problem is real with user research. * B2C: Similar to B>B>C, some segment of users have a need. Identify who they are and what the real problems are. 1.2 Is the Problem TAM big enough Step 2: Why us? Why now? 2.1 Do competitive studies 2.2 SWOT analysis 2.3 Are you best positioned to build this and build now?

There's a lot written about basic PM competencies (https://a16z.com/2012/06/15/good-product-managerbad-product-manager/), and for any PM on my team, they should be able to do all these things you'd expect from a PM (write specs, understand the customer, communicate upwards and outwards, GSD). I'll focus my answer on a few attributes that I think are really "make-or-break" for me: * Good communication skills, both written and verbal, are an absolute must-have for any PM on my team. Whether it's through writing specs, influencing stakeholders, or pitching product ideas, PMs have to be able to communicate effectively across mediums (written, verbal), forums (large groups vs. small groups vs 1:1) and audiences (to developers, marketers, sales, executives). In particular, they need to be able to tell good stories (e.g.,, can they get their team inspired about an idea?), structure their communication effectively (e.g., can break down ambiguous problems using a framework?) and make technical concepts easy to understand for non-technical folks (e.g., can they explain how routers work to someone without a CS background?) * Great PMs "own" the problem. They're not afraid the step outside the boundaries of their function to do what it takes to get the product out the door. They rarely ever use phrases like "that's not my job" or "this was the designer/developers responsibility". Their strong sense of ownership of the problem leads them to passionately debate about the right solution, speak truth to power when necessary, but also be open to other points of view (because it's not about "them", it's about solving the problem).

The level of detail that people on other teams need depends on what they are using the roadmap for. Our roadmap planning tool enables us to create multiple views of the roadmap - we tailor each view to the use cases of the consumers. For example, we have the following views: * A view for our quarterly planning process - this view is primarily used to communicate to execs so it focuses on the high level business goals that each roadmap item supports and doesn’t contain many implementation details. * An internal view that go-to-market team members can use to understand estimated delivery dates for items in active development or beta - this view contains much more detail - for example the user needs that the release addresses and how to sign up for betas. * A public view that is available to our customers - this view contains customer facing explanations of each project and information on how our customers can help us develop it. For example, an item might have a few questions about the customer’s use case and interested customers can send us answers to those questions.

Without going into specifics, the biggest challenge has been cross-organization influencing. My time at both Microsoft and Google has exposed me to lots of intra-organization projects with varying levels of buy-in from each team. The level of effort and coordination required to pull not one, but two organizations in the same direction can be enormous. As a PM - at any level - it's your role to effectively communicate why what you're trying to acheive makes sense for other teams, your company and ultimately your customers. Even if you're aligned on principles and strategies, there are dozens of other factors that you need to be able to navigate such as resourcing, ownership, tech stacks, recognition, branding, leadership opinions and timelines. 

In my mind, it's not an either-or. By growing existing talent, you retain organizational knowledge and build a shared culture, while bringing in external hires inject fresh perspectives and sometimes specialized skills lacking within a PM team. When I am looking at my team structure and needs, I often consider the following: Things to Consider: 1. Internal Development Programs: Promote from within by offering training, mentorship, and rotational programs that broaden your team's exposure. This approach (in my experience) strengthens loyalty, develops institutional knowledge, and keeps your product strategy consistent. 2. Hire Externally: Often times PM teams get into stuck patterns and fresh perspectives are invaluable for a team's growth. When I need new capabilities, like a strong data analytics background, or experience in a specific market segment, hiring from outside will usually shorten the learning curve and bring proven experience to the team. This ultimately helps the broader team as their exposure to these new skills raises everybody's value and potential. 3. Do Both: We need to do both internal development and external talent acquisition to manage the best possible team. Keep growing your internal team by providing new opportunities and challenges, while selectively recruiting outside talent to fill knowledge gaps and bring in fresh eyes. This way, I keep our internal culture strong, ensure continuity / grow loyalty and still gain a fresh perspective when you need it.

No-one can, or should ever be sure that they have a 100% right product strategy. But you can do a lot to de-risk your approach, and your tactics should vary depending on how much time you have to plan. * Is your strategy ultimately going to drive the change in behaviour you want? Find the key participants in your strategy -- e.g. the customers -- and talk, talk, talk to them. You'll learn a ton from the first 5-10 conversations, and suddenly you'll start to hear the same themes and be able to predict what they'll say. Then you can move on. * Read, and connect with people who are familiar with this situation in your industry or other industries. How did things work out? Is the current market / environment similar enough that you can draw conclusions? * The more experienced you are, the more confident you can be about relying on product intuition. A phrase I often use is "we've seen this movie before" and, it's surprising how many times the same situation gets repeated.

FIRST OFF, TAKE A DEEP BREATH AND REMEMBER, CRUSHING THOSE OKRS IS GOING TO TAKE TIME AND EFFORT. NEXT, SET CLEAR GOALS FOR EACH MILESTONE AND BUILD A PLAN AROUND IT. JUST LIKE YOU WOULD WHEN DEFINING A PROJECT, IDENTIFY SUCCESS METRICS FOR YOURSELF AND CREATE A PLAN. HERE’S AN EXAMPLE: First 30 days: Learning and Absorbing * Establish good working relationships with stakeholders: the key to being effective is having open lines of communication with your coworkers. Take the time to get to know them and learn from their experience. * Immerse yourself in data: learn where to find pertinent information, which dashboard to follow and how to query data on your own (or work with a data scientist). * Familiarize yourself with your product’s users, their needs, pain points and Jobs to be Done (JTBD). * Spend time doing competitive analysis to better understand the product landscape. * Integrate into the team’s current work and process and identify ways in which you could be helpful. 30-60: Ownership and Leadership * Assume responsibility for a project: work with your team to define the project’s scope and add requirements. * Define success metrics for the project and work with your engineers and data scientists to ensure impact can be measured and tracked. * Identify cross-functional dependencies and reach out to relevant teams. * Give a demo and solicit early feedback. Continue to do so throughout the project. * Report on the project’s progress and impact to keep everyone involved and interested. Speak clearly about the business impact and how the project ladders up to the company’s goals. 60-90: Strategy and Vision * Leverage your understanding of the business and its users to craft a vision and strategy. * Translate the above into an actionable roadmap and work with your team to define success metrics for each. * Run brainstorming sessions with your team regularly to generate ideas and prioritize them. * Evangelize: this is where your storytelling skills will come into play—make your team’s mission known, its projects familiar and its rationale clear to everyone. Write posts, speak at company meetings and bring feedback back to your team. * Become an expert: be the go-to person for your focus area.

This is a good one. I think there are two that often get missed and largely it is because they are hard to measure and expensive to move. 1. Product excellence. How do you measure customer delight in an impactful way? CSAT and NPS have lots of opportunities to be gamed and are frankly easily ignored. Some of the best products I've used focus on finding the right critical user journeys and continuously measure the success rates of those quantitatively and qualitatively 2. Product health. Cold boot, warm boot, latency for critical actions, crashes, uptime. All of these things contribute to Product excellence but are much more directly measurable and can really sneak up on you

In my previous answer, re: finding the right opportunities + making decisions - I mentioned four lenses (Customer, Business, Market, and Technology) as key components of coming up with ideas and making decisions. The best advice I have to offer is to be intentional about spending time developing your muscles in those areas. It can be as simple as picking a product or service in your day-to-day life and thinking through what inputs might have contributed to the experience you’re having as a user. Additionally, a lot of product strategy is about being able to identify the opportunity that will maximize impact. How will you hone in on the right problem and arrive at an excellent solution? I’ve found that strong problem-solving intrinsics and the ability to make effective decisions are very valuable. Here are two frameworks I’ve always found helpful: * McKinsey’s Seven Steps of Problem Solving - Helps abstract underlying problems/issues * Playing to Win - Strategy book by the former Procter & Gamble CEO A.G. Lafley Lastly, communication is essential for being able to get buy-in and execute product strategy. Work on simple, effective communication.

Great question! The move from Senior PM to Director level and above is a challenging one. In general, the change really involves the transition from product management to product leadership. You are typically going from managing one team at a high level with one roadmap and no direct reports to a role managing multiple teams at a high level with multiple roadmaps and direct reports AND driving an effective vision & strategy for your portfolio that brings those elements together AND provide tools and conditions for the whole org to get better at being PMs. Whew! Given the changes in responsibilities, you’re likely going to have to evolve into performing at the Director level so you can set your” opportunity table” for a Director opportunity. Given where the Senior PM level usually sits, here are probably the kinds of skills and experiences you’ll need to try to acquire: 1. Learn how to manage and mentor people. Does your company hire interns? Manage one or more of them! Does your company hire new people that need mentors? Become a mentor! Manage people volunteering somewhere! There’s lots of ways to get skills and experience here, great books too (Leaders Eat Last by Simon Sinek I highly recommend.) But in general the best teacher for managing people is experience. 2. Learn how to build product strategies at the portfolio level. If you’ve gotten to the Senior PM level, you probably know how to develop a strategy for your product or feature. But doing this as a portfolio level is different. It requires thinking longer term about multiple teams with multiple strategies & roadmaps. The best way to learn this skill is to take on the responsibility of doing this or sharing it with your boss or higher-ups. This is a stretch to do in the beginning, but the more you do it the better you get at it. Some good practice is also crafting strategies for products you like or companies you admire. See how many of them come true and how right or wrong you were. Learn, rinse and repeat. I also recommend Good Strategy, Bad Strategy by Richard Rummelt. Amazing book on this topic. 3. Help your fellow PMs in the org level up via skills like org design, policy design, tooling upgrades, etc. Basically practice the art of leveling up a team by creating an environment for PMs to level up and do great work. Think about your own experience doing your best work. What kinds of tools, policies and cultural norms were in place that really helped you level up? Now think of ways you can get from where you are today to that ideal. What tools do you need? What policies need to change? How does the culture need to change? From here, learn how to drive the highest priority items. You don’t need to be a Director for this, you can pursue it by speaking up in feedback forums on these topics, work with your peers or managers to make things happen, etc. If someone was taking initiative here, you can bet managers will be considering them for leadership spots. That’s the high level summary! The opportunity actually presenting itself requires being at a company where there is a need for someone at that level, which requires a bit of luck and timing. So all places aren’t going to be best fits for you, and you should assess that on your own as well. As for types of tracks, PM leadership skills are pretty transferrable. Director, Senior Director and VP are more traditional paths. But I’ve seen old bosses and colleagues go lots of different ways. Something I hear a lot is that the PM role prepares you for being a start-up CEO. Have certainly seen that happen! An old boss is CEO now. But I’ve also seen lots of people end up in Marketing, Design, Engineering, Strategy…there’s no one set path!