* Resume: Usually, the biggest red flag for me in a resume is when either the candidate doesn't describe any impact metrics or focuses on a vanity metric, eg, if a checkout PM describes an increase in the number of payment page views instead of an increase in checkout conversions * Initial Interview: PMs are often advised to use a variety of frameworks for their interviews primarily to showcase a PM's structured thinking to a problem. This is good advice as long as the PM uses a framework for reference instead of answering questions with the framework alone. As a hiring manager, I am more curious about how you thought through a problem, what real-world challenges you came across, and what the outcome was. The idea in an interview isn't to understand a PM's knowledge of the various frameworks available but to understand the depth and breadth of their thinking in a real-world use case.

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

If you know that customers are not willing to adopt your solution, that's a bad spot to be in. 1. Re-evaluate what led you to the decision to build & when to do it. Was there a gap in your methodology, or a piece of research that led you down this path? How can you avoid this for the next piece of strategy planning? 2. Don't hope for better adoption -- test and prove this out. Can you get a high quality signal that customers will adopt, e.g. customers will pay you now for access to it? 3. Is there a wider org that will bear the cost of holding this solution, and values it for reasons other than direct revenue?

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.

The following stand out to me for what I've witnessed: * The team is acting like the product they're creating is going to be successful. I'm amazed at how many successful companies try to build new products like they do for their existing successful ones: same processes, same success metrics, etc. They don't have the urgency, move too slowly, learn too little, are complacent. The market is a graveyard of failed products and businesses: the most likely outcome, when creating a product, is that it will fail. As a result we shouldn't assume success but instead focus on doing everything we can to de-risk, test and validate - and make sure we don't over-invest too early. I recently was interviewed in Lenny's podcast to talk about that: if you're working on 0-to-1 in a bigger company I think it's worth your time. * The team built a solution to their own problem and they assumed that many more people would face it in the same way. We hear a lot of success stories that started like that, and while it's true that some successes began like this, it's also where a lot of failures came from. You're not the customer of your product: work with real customers! Or it's only going to work for a small population, and that may not make it a viable business. Mehdi, the founder of Cycle, shared openly a great example of this for how they changed their approach to user onboarding. * The product manager tries to get a big team from day 1. Honestly a small team can move 10x faster than a big one. You need a team of people you can trust who can move mountains on their own and continents together. For the first year of creating Jira Product Discovery we only had 5 engineers, and we moved really fast. It forced us to focus on the most important things, to be nimble and creative when testing solutions, and we could do this with very few meetings (it's very easy to get everyone on the same page at that scale). Once you've proven you have a solution that solves real problems for a small number of users - you can then go back and ask for a (slightly) bigger team. Resist that urge to grow too fast! * The team is fighting too many battles at once. This happened to us at Atlassian when we tried to rebuild Hipchat into another product called Stride. We were trying to launch a new product built on top of a new platform that could be used for all other Atlassian products. We faced this tension product<>platform from day 1, and it was much slower to move on the product front. Like with any failure there's of course more than one reason this product didn't pan out, but this is definitely one of them. * The PM fails to get the right level of buy-in internally - if it's about creating a product inside a bigger company. It's very important to "build chips" in the company (gain trust from leadership) so you can spend them, gain more chips, etc. And it's key to communicate your learnings and progress in a way thatmake your team look like a high speed train - no one wants to get in front of a high speed train. This is one of the topic I cover in an interview on Lenny's podcast.

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.

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.

This question is very similar to the question about knowing that your strategy is successful, but I’m going to look at them through two different lenses. For this question, I’m going to look at it as a strategy for a new product that hasn’t been introduced yet, you have no active users, and you want to figure out if your strategy is the right one before you launch. To validate a strategy in this situation, the approach has to be proactive and thorough. The goal is to ensure that when you deliver the product to users, it gains traction and starts building your user base right from the get-go. Here’s how I approach it: * Market research and user persona development: Before anything else, deep market research is critical. Understand the market landscape, identify gaps, and pinpoint the needs that your product aims to fulfill. Develop detailed user personas to represent your target audience. Knowing who you’re building for and their specific pain points helps tailor your strategy to meet real needs. Writing jobs to be done (JTBD) is a great way to distill what you've learned. * Problem-solution fit: Validate the problem-solution fit early. Engage with potential users through surveys, interviews, and focus groups. Present them with your product concept and see if it resonates. Does your solution address their pain points effectively? Are they excited about the prospect of your product? This feedback is essential to refine your strategy before you even write a line of code. * Competitive analysis: Conduct a thorough competitive analysis. Understand what similar products are doing well and where they fall short. Identify your unique value proposition—what sets your product apart? This differentiation is key to attracting users in a crowded market. * Pre-launch campaigns: Depending on the product and market, run pre-launch campaigns to generate buzz and gather initial interest. Create landing pages, run social media ads, and engage in content marketing to build an email list of interested users. Measure the engagement levels and adjust your messaging based on what resonates most with your audience. * Pilot programs and user testing: If possible, run pilot programs with a select group of users from your target market. This can be done through partnerships or exclusive invites. You don’t actually need to have a real product to show them—wireframes and designs can be enough, at this stage. Collect feedback on their experience, what they love, and what could be improved. Iterate on this feedback to fine-tune your product. * Metrics and KPIs: Establish clear metrics and KPIs to track from day one. These might include sign-up rates, engagement metrics, conversion rates, and feedback scores. Thinking through these before you start to build helps you to focus on what you believe will make your product successful. Once you do have something available for customers to actually use, having these metrics in place helps you measure the initial traction and adjust your strategy based on real-world data. * Minimum Viable Product (MVP) testing: Once you have a good understanding from all of the above, build an MVP to test your assumptions. The MVP should have just enough features to solve the core problem for your target users. Release this to a small group of early adopters or beta testers. Their usage and feedback will provide great insights into what works and what doesn’t, allowing you to make necessary adjustments. * Feedback loops: Create robust feedback loops to continuously gather user insights. Use tools like surveys, in-app feedback, and user interviews to keep a pulse on how new users are interacting with your product and what their pain points are. This ongoing feedback is crucial for making iterative improvements. * Alignment with business goals: This is the same as when you have a product that already has usage. Ensure that your product strategy aligns with your broader business goals. This involves regular check-ins with stakeholders to confirm that your product direction supports overall business objectives. Misalignment can lead to strategic drift, where your product might be developing well, but not in a way that supports the company’s long-term goals. In the end, validating a product strategy for a new product involves a mix of thorough research, proactive user engagement, iterative testing, and continuous feedback. Ensure that your product resonates with its target audience. All of these things will help you build confidence that your strategy will enable you to gain traction and grow your user base effectively once you launch.

The easy answer is ideas come from everywhere—customers, sales, internal teams, data, market trends, a founder's morning shower epiphany, etc. In reality, what matters most is having a clear system to prioritize them based on impact, not who yells loudest. I don't think you take an idea and then just go and build it. You need to look at the ideas holistically and in a larger context. Are they hinting at a one-off problem or an endemic one? Use all the noise of the requests to triangulate the customer problems. Solve those and you'll be doing just fine.

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.