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

You should think of it as: it should be ready to be shipped when it's the first shittiest version, and when it's the best version of itself. The question should not be not so much about readiness of the solution, but readiness for whom? I've witnessed teams who got too excited when creating a new product and opening the floodgates to let anyone try it too early. That usually doesn't end well... You don't want many people jumping on the solution when it's not ready for them: first impressions won't be good, they won’t stick around and you'll need to work hard to get them to try again. Here's the approach we take in my teams: basically, for anything we ship, whether that's big new features to Jira Product Discovery or new products (including Jira Product Discovery itself), we work with progressively more customers (10-100-1000) before making it generally available. It helps us test the solution very early with a handful of customers to get feedback and make sure the solution delivers on its promise for them, and ensures that everyone only gets the solution when it's ready for them - thereby increasing retention & minimizing churn. If you want to learn more you can watch this talk I gave about the process we went through when creating Jira Product Discovery. You can also read more about this topic in the Atlassian Product Discovery handbook, that we wrote to help with things like this. 0->10 customers (preview) In the first phase of early stage bets we only work with max 10 customers. We unpack the problem and test solutions and iterate fast, which is a process that’s best done with a small number of users/customers that feel the problem the most. And we get the solution right for them. It’s easier and much more focused to do it this way than “throw it out there and see what sticks”. Users who feel the pain the most will be happy to work with us, we can chat with them on Slack/Zoom/Email easily. They're happy to work with incomplete solutions (we can take a LOT of shortcuts) and we can remove the need to pile on untested assumptions. If the solution doesn't work we can throw it away, it's cheap, no harm done. To demonstrate progress to leadership we use metrics that best represent what we're trying to prove at each phase. We started with the following for the private preview of Jira Product Discovery: 10 active teams have been using the product for more than 3 months and plan to continue using it when we enter beta 10->100 customers (alpha) Then we progressively invite more customers to use the solution. At this stage we usually need to polish rough edges and address more scenarios based on what we learn from working with customers of varying needs, and maybe less willing to work with a rough prototype. It's also harder to collaborate with every customer 1-on-1 so we need to create better onboarding material, demo videos, etc. We move support to a community forum. Our success metric at that stage when creating Jira Product Discovery was still focused on problem-solution fit, but for more customers: Product market fit score of 40% or greater with 100 active teams (I highly recommend the Product market fit score survey, and you can read all about it here) 100->1000 customers (beta) At some point we become ready to share with more users, in our case for Jira Product Discovery it was when we reached 50% PMF score for more than 100 active teams. At that stage we needed to focus on making the solution fully self-service - we couldn't afford to have to talk to every customer once in their journey. So we focused on in-app onboarding, we improved usability, we polished the design, we scaled the technical implementation, we trained support and sales teams, etc. It's really about making it ready for prime time. It was also time to change how we measure success by introducing more metrics that represent the health of the funnel as more customers discover, try and adopt the solution on their own. That’s when we started adopting pirate metrics (AARRR), and here's a great read about them. In the early days of that stage we also focused on validating a pricing model, but that would be a topic for another post. Once we were done with all that, had high PMF score for 1000 customers, healthy conversion rates and retention, low churn, validated pricing - that's when we decided to make Jira Product Discovery generally available. These phases work for us - it doesn't mean they will work for you, but I believe that this general approach should apply to a lot of contexts. Basically: don't focus on "when the solution is ready to be shipped?" but "who should we be working with right now based on the state of readiness and validation of the solution?"

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.

Develop a product mindset: For early career PMs from a skillset perspective, choose whether consumer, enterprise, or developer products appeal to you the most. Do a side project and build your own! Pick a few products with that persona (e.g, pick three of your favorite consumer tech products) and understand how users interact with the product, the pain points they face, what could be improved, industry trends driving that product. Your goal is to start developing some understanding on market trends and how user experiences could be improved. Look for established PM programs: For early career PMs from a recruitment perspective, look for established PM or APM programs with good career development programs & mentors. PM can be different in every company you go to and learning the art of PM at a larger company first and then applying it at earlier stage companies later in your career can serve you well. From an interview perspective, great resources exist online for PM interviews, developing a PM oriented mindset etc. I personally feel product management is a better suited career after a few years of experience in a domain building role (e.g, software engineer, PMM etc). As a PM if you can bring a point of view on the domain you will be operating in and some experience of the market, user, tools and GTM motion it will enable you to be a more empowered PM.

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.

Here are some of the areas one can look to potentially increase engineering team velocity, i.e. do more over the same period of time. * Cross-craft collaboration: PM, UX and Engineering. Do you make decisions quickly, or spend a lot of time debating the direction? Do you trust each other? Do people have to go back to PM for clarifications all the time (and stay blocked, while waiting for such clarification)? * External dependencies: are you sell-sufficient working on your thing, or have to rely on other teams’ deliverables and timelines? Can you either influence priority of your external components, or own all of it end-to-end if it's the latter? * Motivation: is the entire team bought into a grand idea of your thing? Do they consider it fun to work on it? Or people just “clocking in”? * Roadmap efficiency: do you frequently have to go back and re-do a thing? (e.g. late requirements or design changes) Is one-off, throw away work common on your team - or you are building with one brick over the other? * Tech debt: PM nightmare - stopping working on new features for a while. Yet sometimes team may see opportunities to modernize their codebase - unlocking unbelievable velocity for the future. Decide together if it's an "okay" time to do it now (it is never a "good time" from a PM point of view, and always is from Engineering point of view) * Perceived velocity: is your team working on something behind closed doors for a long time, or is open to share exciting, tangible, easy-to-consume updates every week? The latter would help external stakeholders to appreciate team’s velocity way more. At Atlassian, we foster a culture of micro updates (think of a Tweet-size shareout) shared every week - and we have a platform component Goals & Projects to enable this process at the organization level.

Many data-driven Product Management (PM) teams often overlook long-term strategic KPIs, such as Customer Lifetime Value (CLV), by focusing on short-term metrics like quarterly margins or one-off transactions. This approach can be detrimental, as retaining customers typically yields higher CLV and reduces churn-related costs. Another critical KPI often missed is Feature Discoverability and Time to Value. Despite having sophisticated features, users rarely utilize them due to: Difficulty Finding Features: Users struggle to locate necessary features. Longer Time to Realize Value: Understanding and realizing the benefits of these features often takes longer than competing alternatives. By prioritizing these long-term strategic KPIs, product teams can enhance adoption rates, accelerate customer value realization, and ultimately drive sustainable growth and customer loyalty.

1. Understand the current product vision and why it’s not working: This usually stems from a lack of product-market fit. It’s important to identify the gaps and why the current vision is failing to resonate with users. 2. Talk to users: Engage with as many users as possible to understand their pain points and the core problems they need solved. This insight is crucial to shaping the new vision. 3. Understand the market: Analyze the Total Addressable Market (TAM), identify competitors, and learn what's working for them and what isn’t. This will give you a clearer understanding of the space you’re operating in. 4. Consult experts: Talk to people who are knowledgeable about the space—investors, VCs, former colleagues, other product leaders, and experts. Gather their perspectives on the market and the potential for success with a new vision. 5. Brainstorm with stakeholders: Collaborate with key stakeholders, including founders, engineering leaders, the extended product team, and the marketing team to brainstorm potential pivots. 6. Decide on the new pivot and validate it: Once a new direction is identified, validate it through user research. Make sure it addresses real user needs and aligns with the insights gathered from the market. 7. Write the new product vision statement: Clearly articulate the new long-term vision for the product. 8. Stakeholder Alignment: After writing down the new product vision and before proceeding with the MVP, it can be helpful to ensure alignment with all key stakeholders—executives, board members, and the broader team. Getting everyone on the same page regarding the new direction can prevent potential misalignment down the road. 9. Define the MVP: Decide on the minimum viable product (MVP) that you’ll need to start validating the new vision. 10. Defining Success Metrics Early: When defining the MVP, it’s useful to also outline clear success metrics upfront. What does success look like for this new pivot? It could be user adoption rates, revenue milestones, or customer feedback. These metrics will guide the evaluation of the new pivot and help you determine when it’s time to double down or pivot again. 11. Build a POC with engineering: Work closely with the engineering team to quickly build a proof of concept (POC) for the MVP. 12. Present the MVP to key stakeholders: Present the MVP to investors, colleagues, customers, and prospects. Revalidate the solution through their feedback. 13. Assess willingness to pay: See if customers are willing to pay for the solution. This will help gauge market interest and potential success. 14. Evaluate the pivot: If the feedback is positive, proceed forward. If not, be ready to pivot again and quickly move in a new direction. Throughout this process, speed is critical. If at any point it becomes clear that the new pivot isn’t the right solution, it’s important to pivot again as soon as possible.

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.