Ultimately Product Management is about people. I do approach stakeholders differently, but it’s based on who they are, rather their role. Some stakeholders like to be consulted ahead of time, some prefer being briefed in bigger forums where they can gauge the reactions of others. Some like structured approaches, others react to the anecdotal evidence. Some may have specific trigger points on specific topics. Part of my role is to understand those differences and be able to navigate through them.

I think the best way to break into the industry as a PM is to get after building tech products yourself. Personally, I left a well-paying job in the energy sector to work on a start-up with no reliable paycheck. Thinking back on that experience, it was crazy beneficial to learn how to work with designers & engineers to build a great product or feature. The act of building a product or feature is the best teacher. I’m not advocating that you should quit your job and not get paid to build stuff like I did! There was a lot that wasn’t so awesome about that. 😅 But I definitely WOULD encourage everyone here to think about how you could do that in your spare time. What problems are you passionate about solving? What kind of product or feature could help you solve that problem? How could you bring that solution to life? How can you talk to prospective customers about it? Even PM candidates that make wireframes or prototypes to show a product that solves a real problem have a leg up over most of the other candidates. I’ll take someone with drive, initiative and passion for the work 10 times out of 10.

A super common question! Traditionally the term "product manager" can often mean different things depending on the size of the company, the product's stage, and sometimes the overall market segment. I often times bucket them into these core groups: 1. Technical Product Managers (TPM): These PMs work closely with engineering teams on more technical products, thinks like API driven products where the end "customer" is technical in nature. For these roles, you will need a deeper level of technical expertise and the ability to understand the technical aspects of your customers needs. 2. B2C (Business to Consumer) Product Managers: In a consumer-facing environment—like mobile apps, e-commerce platforms, media consumption products — I find that PMs often emphasize UX and product design (along with core PM responsibilities). One of the key areas that this group focuses on is leveraging a typically broader/larger customer base to do things like A/B testing, and quick iteration on product designs to validate assumptions and feature value. 3. B2B (Business to Business) Enterprise Product Managers: These enterprise PMs focus on delivering products that solve businesses' complex problems. I spent a lot of my career here and this type of PM spends a lot of time on sales enablement, strategic account engagement, and roadmap management. Given that most B2B solutions have a longer sales cycle, their relationship with sales is key to success. Depending on the size of the organization, this type of PM also focuses a lot on the financial side of the product. 4. Infrastructure Product Managers: These PMs (sometimes internally facing only) focus on building components that other teams and products rely on, oftentimes within an organization. For them, the GTM isn't as relevant but they need to understand and balance things like scale, interoperability, and business alignment. Figuring Out Your Best Fit: 1. What are your Interests: Consider things like Do you enjoy getting into the weeds on technical discussions? Do you more get energized by user research and design? Do you geek out over analytical data and love looking at usage metrics to drive feature development? Each type of role has a different focus, so find the things that excite you. 2. Consider the Environment Do you want to reach a huge market of customers and iterate on minor feature developments and enhancements? Or do you want to work closely with larger business customers and develop a deeper understanding of their problems and how your product can evolve to meet those specific needs? No right or wrong answer, just what gets you pumped up each day. Remember, it’s about aligning your career desires, your core strengths, and the types of challenges that get you fired up to solve each day. We are problem solvers, so what types of problems do you love solving and how do you like solving them? Many PMs start in one area and end up in another. All the roles share a common framework of ensuring we are delivering business value for our organization and delighting our customers with innovative and useful solutions to problems they either have or don't even realize they have yet.

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?

My “north star” vision for the Product Operations team is to “unlock Oscar’s ability to ship more product, better and faster.” While this is a pretty broad statement, I want to highlight a few elements. 1. Product Operations is not a function to make the life of a Product Manager better or easier. We do not “support” Product Managers. Our focus is unlocking Oscar’s capacity to ship software. In our context, this means that Product Ops focuses on the goals and delivery of our engineering pods. If there are opportunities to increase efficiency of engineering or design, those are on the table. 2. Product Operations adds value in a few different ways. Here are a few examples: * Ship more product - We can maximize the time each member of the pod is spending at their “highest and best use.” This may mean that Product Ops takes on execution oriented work while we advocate for automation or create an operational process. * Ship product better - We can improve product quality by ensuring that we follow necessary testing protocols, or ensure downstream teams are fully enabled before product releases. * Ship product faster - We can create efficiencies by building repeatable processes and playbooks, both for ourselves and for other stakeholders. In real life, this might manifest as a Product Ops Manager taking on the product launch process for a particular pod, which frees up capacity from the Product Manager and the Tech Lead (ship more product). Product Ops can ensure that their operational counterparts have visibility into the feature work and are communicated about launches in a timely manner (ship products better). Product Ops then codifies this improvement by creating a product launch checklist for themselves and other feature teams, thus avoiding “recreating the wheel” for each team (ship products faster).

I've noticed a trend in the tech industry for product organizations to follow a structure that Spotify helped craft over the years, in which a company is organized into business sub-orgs that roll up into their own respective product and engineering leads. And those leads oversee various squads that make up the product areas within that sub-org. At CookUnity we call the product areas "zones", in which a product lead exists to drive the product strategy and manage the PM team. In smaller companies (<500), those product leads are likely the direct leadership team for the Head of Product. You can follow this model at any size company, you'll just see a different scale of how many and how big the sub-orgs are.

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.

Start by showing interest and taking steps in your existing role. Work with your engineering manager or the PM on your team to take on PM work. You can listen to customers calls, gather insights and turn those into a feature or investment proposal, or perform competitive research and synthesize that into an action plan for your team. The best place to make the transition is at your existing company, where you have already built trust and there is someone who's willing to work and invest in your development.

Oh, this is a tough one! Since the AMA is about Technical Product Management, I'll answer from that perspective. It's common for a successful company and product to face tech challenges after they've achieved significant growth. When you're a startup moving fast to find product-market fit, you might not prioritize the technical hygiene of your product. Then, as you scale up, you may need more time to go back and clean up or improve your technology. Eventually, this issue needs to be addressed, as outdated tech could limit future success, pose security risks, or even hinder expansion into new markets. I've been asked to lead product and R&D teams through situations like this, which can be extensive, multi-year efforts. My biggest takeaway is that more than focusing solely on technology is needed. It's easy to say, "Our tech stack has reached its end of life, and we need to adopt this new one." But stakeholders, like executives, customers, partners, and investors, care about business results. So, always frame your work regarding the outcomes you'll create, such as faster scaling, improved product experiences, or reduced operational costs. By emphasizing these outcomes instead of just the technology, you'll gain support from key stakeholders, which will help you secure the necessary time and resources for success.

The most important thing you can do as a new head of product is to align with the founder/s and/or your manager on what your role is. Most people assume they did this in the interview process. Yet, misalignment on this question are the most common reasons heads of product fail. You want to know: 1. How will I be evaluated? “In 1 year, what evidence will tell you I’ve been successful?” Make sure they are specific. For example, if they say something like, “customers are happier,” follow up with: “what’s an example of something that would give you confidence customers are happy” This tells you what outcomes you’re being evaluated against. 2. How much autonomy will I have for which product decisions? The best piece of advice I've received is to ask a new manager or founder, "What decisions do you want to make? What decisions do you want me to make but run by you first? What decisions do you want me to run with entirely?" This tells you how much autonomy you have on what. Once you understand these things create a 6 month plan that incorporates a few things: 1. Quick wins - ask your manager, their manager, your team, and your peers, “what do you need most from product management?” Use this to identify a few quick wins you can deliver to build trust. 2. Start with the low context decisions - a lot of new Heads of Product make the mistake of trying to define a product strategy too early. This is often a mistake because such decisions require product context, organizational context & an intuition for the space. Instead start by making decisions you don’t need a lot of domain context to make - who to hire, how to uplevel the team, how to improve your product process, etc. For product decisions, start small by picking a few projects/or areas to go deep on before building out a larger strategy. In all of this, setting expectations is your best friend. Once you’ve aligned with your manager on your plan, be sure to set expectations with the organization about what you’ll be focused on in what order.