There are many potential signals – just one of these is enough! * You're starting to hear the same problems repeated in a lot of your research * You don't have a clear view of feasibility of the solutions you're thinking of (you need to start prototyping) * You have a potential customer willing to pay for the solution you've shared with them Bear in mind that bringing eng resources to the project isn't a binary, and you should be partnering with an eng lead from the start of your discovery so they can pressure test your ideas and explore potential architecture/approaches in parallel. You'll need to prototype and validate before an entire squad starts building, of course. Think carefully about how much engineering resource you need - always start as small as possible, as larger teams have more operational overhead.

Of course they do! It's always a balance between those two sides. Mixing personal contributions with coaching other product managers can create tension if you’re not mindful. Setting clear boundaries around your schedule, defining what success looks like for both you and your team, and communicating these goals openly helps manage these two aspects. Things to Think About 1. Dedicated Coaching Time: I try and dedicate time each week to ensure my team is getting what they need and that I am providing them the opportunities to grow and gain exposure (to new skills, new teams, etc). If the team feels disconnected from their leadership, it's difficult to motivate them and keep them moving forward. 2. Defining Ownership: Whenever possible, I clarify what parts of the product I’m responsible for and what the team needs to own. When PMs clearly know what’s theirs to drive, it reduces the urge for me to dive in and micromanage. We play to our strengths, which allows me to contribute where I add unique value (eg: shaping high-level strategy or unblocking critical issues) while allowing each team member to do the same in their areas. 3. Regular Reflection: Every week and month, I reflect on where I’ve been spending my time. Did I neglect my direct product work because I was too hands-on with the team? Then I need to adjust next week. It's a constant balancing act. As I said, I work to carve out space, define ownership and teach PMs to solve problems independently, All of these ensure that your individual contributions and coaching efforts reinforce each other rather than work against each other. Over time, your team grows, and you free yourself to have a broader, more strategic impact.

PMs should define the success conditions in the strategy (e.g. 20% market share, or $20M attributable revenue in H1 etc). Those success conditions should: * Ladder clearly up to the needs of the org or company * Define a realistic stretch goal, ideally validated through customer discussions or other qualitative or quantitative research -- including timelines * Cover direct and indirect effects as needed * Include countermetrics or contraindications that define changes to be avoided

While project management and product management require similar soft skills (communication, negotiation, structured approach etc.) there are some fundamental differences. For instance, project managers need to be risk averse because their job is to make sure projects are delivered as promised. Whereas, product managers must have a higher risk appetite as their job is to maximize outcome for the business and must explore unconventional paths get to the outcome. So it's important to recognize that these are fundamentally different jobs and approach product management career with a sense of curiosity. Other than, the approach to getting into product management is the same for people transitioning from any other craft. The easiest way is to find product management opportunities within your current team / organization, rather than job hunting in the open market, because they already know you and your work.

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.

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.

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.

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.

Different types of PMs - Core Product Managers, Platform Product Managers, Infra/Internal Product Managers, Data Product Managers, Growth Product Managers, AI Product Managers Core Product Management * Building products, features, enhancements directly for the company’s external target consumer/business Platform Product Management * Building products, tooling, systems that are leveraged/shared by a handful of core product management teams to prevent service duplication - ie billing systems, authentication services, localization/globalization/accessibility tooling, design systems, graph services, etc.. Infra/Internal Product Management * Building products, tooling, frameworks, processes to accelerate the productivity of internal stakeholders in the company (developers, designers, GTM, marketing, analysts, etc..) Data Product Management * Like infra/internal product management but building warehouses, ETL, clean datasets, databases, query tooling, visualization software, to empower the productivity of data scientists, data analysts, ML engineers, etc.. Growth Product Management * Defining and executing on flywheels, acquisition levers, engagement/retention incentives, new feature introduction mechanisms, etc.. to ultimately acquire more customers, ensure they use the right products, and win them over as life-long champions of the product. AI Product Management * Leverage open source or commercial software, input customer/product data into it, tune/tailor it to your business, build an custom interface on top of it, to ultimately generate recommendations and/or outputs that empowers your customers to meet their goals * And/or build in-house, proprietary machine learning algorithms to accomplish the same as above Oftentimes, the titles above to match what the company decides to call you - which is just Product Manager :) Some PMs are also expected wear multiple hats here.

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.