Prioritise with respect to the key goal that is important to the org -- but balance with your estimation of what you think can land. That sounds simple, but in large matrixed organisations, that can get hard quickly. * Sometimes it's not clear what advances the org's goal -- is there a key metric? Can you forecast a project's impact on that metric, and is that forecast credible? * If shipping a particular project needs alignment from lots of teams, do all of them share the same incentives you do? If not, can they support your goals, or will they deprioritise?

I don't really have a "scientific" answer to this - I've always done this in 2 ways: creating a bottom-up model, and trying to find data from other companies/competitors to benchmark against. Bottom-up model I've usually done this in a giant spreadsheet, trying to build a model with a lot of documented assumptions. Here's how we did it for Jira Product Discovery: * First, decide on how we would package and price the product, which we did via conversations with our early lighthouse customers, a survey, etc. We landed on: per user pricing, some users pay, some users don't, at a price of $10/user to promote collaboration use cases (we didn't want the price per user to be a blocking point to invite more people to collaborate). I'm not an expert at this but I highly recommend this conversation between Lenny and Madhavan Ramanujam on "the art and science of pricing" * Then, estimate how much revenue, based on that, we could get from the current customer base in the beta. We ran a beta for about 18 months and had > 1000 companies using the product for free. We made assumptions about how many of them would buy the product based on their usage of the product and what we knew about them from our other products (e.g. if they're already paying for Jira, if they're paying for more than one product, etc.). We already knew how many users they had on Jira Product Discovery, so with a price of $10/user we were able to estimate initial revenue in the months following general availability * After that we estimated sign-ups and conversions. * For that we used the data we had from sign-ups and conversions from the beta, we adjusted it (because beta was free), and we compared with sign-up and conversion rates from other products at Atlassian - some were a good benchmark (early products), some were not (more mature products). * We also estimated the impact of experiments we would run to try and recommend the product to existing users of Jira. We knew this was going to be our main distribution strategy, which we had validated via a few experiments already, so we had some data to work with. * Based on this we came up with a guesstimation of signups / month, conversion rates from trial to free/paid (which would go down in time as we reach more customers who are not early adopters), we took into account an element of churn, we estimated the number of users per customer (based on beta users, and also assuming we'd progressively reach bigger companies), etc. * We added to the model future initiatives that could impact revenue - for example the launch of a Premium plan at a higher price point. * Etc. - basically we built a bottom-up estimation based on everything we knew (data) but also bets into the future (new features that make the product appealing to more customers, new plans) The model is usually wrong at the beginning, but it does get better over time as real data comes in. Benchmark with competitors At the very beginning of the product, before we even wrote a single line of code, we tried to assess the TAM/SAM/SOM. There's a lot of literature online about how you do that. What I found works best for me is to assess this by proxy, by looking at other players in the market/competitors. You can find a great deal about a company by crawling its blog, finding out who is in charge, look for talks they gave, opinions they give online, etc. There is so much information online. For example: a competitor might claim they have X users, and you can match that to their pricing structure (public information) and estimate their ARR (Annual Recurring Revenue). They might boast on a podcast that they have 80% growth in the past year - that gives you an idea of their momentum. Do that for a few companies and it gives you an idea of the current size of the pie and how big the pie is growing. And you can decide how big of a slice of that pie you want/need in 1-3-5 years for this to be worth it. Careful though: another company making $100M ARR is not a guarantee it will be the same for you: it also depends on your business model, pricing and packaging. -------------------------------------------------------------------------------- By using a combination of these 2 approaches (bottom-up, top-down) you can usually get to a decent answer. But remember all this is bullshit up until the moment where customers take out their credit card! So make sure to find ways to keep testing your prospects' willingness to pay from very early days.

There is a a shift from from execution to influence & strategy. Earlier in your career you are often helping drive the product to launch and collaborating with a large group of stakeholders to make it happen. As you become more senior, your role shifts to influencing product strategy based on your experiences from the market, competitors, and customers. In this phase you have to be effective at defining and articulating the strategy, then influencing across the organization to adopt, and then leading various cross-functional teams to drive execution, metrics, and long term success. Additionally as you get more senior you have to be looking ahead 18-36 months to really set your product vision up for long term differentiation. 

I find that there are 3 basic traits that a team looks for a product manager to provide in any project: * Create Clarity - Does the product manager have the ability to disentangle the many signals a team may be sorting through and help everyone get aligned on a plan or point of view? * Generate Energy - Can the product manager effectively create momentum the team needs to get a project done? In early career stages, this is often the daily mechanics like running the stand-ups, prioritizing the bugs in a timely fashion, quickly and decisively resolving open questions and so on are all things that help a team build energy and momentum towards delivery * Deliver Results - It’s important to show that you have the ability to put points on the board - both individually and through leading your feature team. Knock out some items that have been on the backlog for too long, help see that stubborn feature thats been stuck in development for too long thru to delivery. If you can show to the team multiple examples of being able to do the above 3 core capabilities consistently and repeatably, I expect you’ll build trust and influence with your new team well.

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.

There are two ways to think about what the right KPIs are for your product and product team. One is to use a general model of customer lifecycle and the other is to align closely with your company’s overall goals and north star metrics. For the general customer lifecycle framework, a good place to start is defining metrics for each lifecycle category: discovery, acquisition, activation, engagement, retention, revenue (if applicable). Now not every product has every category, but this will get you a good place to start. This framework works for internal and platform teams as well - I know since I use it with our platform teams at BILL. While you can start with this lifecycle framework, you will want to make sure to align to the company’s core KPIs. You will want to make sure any metrics that you select within the customer lifecycle framework roll up well to the overall metrics the company is trying to move. This will help ensure that all of the metrics you are monitoring are aligned with the company direction. I will also call out that defining the right KPIs to understand and monitor day-to-day is not the same as setting goals. KPIs are intended to help you understand how your product is performing overall. Goals / OKRs are your commitments to specific ones that you want to move or change. So defining KPIs are a very important first step to get visibility into product performance, then you can get a clearer picture of where you want to focus your roadmap to make meaningful changes. 

While I don't believe there are a lot of different types of AI Product Managers, in some large organizations I see two types of AI Product Managers - 1) application focused and 2) AI foundation focused. It also varies based on the size and maturity of the organization. The Application focused AI PM is thinking a lot about how can you leverage the AI to deliver the best customer value, which customer problems can be solved better if we applied AI and then focus on the adoption of AI. The Foundations AI PMs role is focused on working much more closely with the data science teams to innovate, decide what types of AI models to leverage, ensure that the processes we leverage for AI are compliant, build data anonymization pipelines, data acquisition and labeling tasks are performed and the infrastructure is scalable in a cost affective way. In smaller organization if you join as a product manager, it is highly likely you are the only Product manager doing all of the things. Hence, these lines get blurred in different organizations.

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.

When creating a product vision, it’s important to capture the "why" behind what you're building. These are the key questions I ask myself: 1. Who is the product for? The vision must be customer-focused. Understanding who you're building for is the foundation of a successful product vision. 2. What problem are we trying to solve? This extends to assessing what other solutions exist and what workarounds people are using today to address this problem. A clear understanding of the problem sets the stage for the vision. 3. Is this achievable? The vision should be ambitious and inspirational—like a stretch goal—but still attainable. It should motivate the team to be excited about what they are building while ensuring the goals are realistic. 4. Is this clear and concise? Your vision should be easy to understand. If your non-technical friends can grasp it, it means you’ve communicated it clearly. 5. What is our solution’s competitive edge? Why would users choose this product over others? Understanding your product’s unique value proposition is key to standing out in the market.

Expecting glory right off the gate. The thrill of launching a first test is huge. The disappointment from reality vs. expectations might be huger. Any number of things may go wrong in the beginning. Something may be off with the test setup (dang, that missed attribute), the test might fail gloriously (think big red stat sig negative), the test may be a disappointing win (whoaaa….wait, that’s it? I was hoping 10X impact…), or something totally out of one’s control derails the test (sorry, data outage mid-way through the test, need to run it again). First time (and not first time) growth PMs must instead focus on the bigger picture. Really understand your customers, the product, the market landscape. Be curious. Understand the opportunities (user pain points, drop off points in the experience, greenfield areas), the underlying growth loops, chart your unique learning agenda and then the roadmap needed in place to tap into all of these. Drive the roadmap diligently, bring back learnings effectively. With this, you will build your credibility - a currency much needed to then drive collective creativity and audacious ideas within your org.