It's prevalant myth that PMs make all the decisions. They make some of the decisions but not all of the decisions. But, a PM is definitely responsible for making sure their team can make high quality decisions at a fast pace. They do this by making sure their teams have access to the right information at the right time. Some examples of how successful PMs do this are 1. Helping the team understand the company / department strategy - This is typically presented to the team as the business context driving the team's work + adjacent teams / departments and their strategies. 2. Bring the customer voice to the team - This is typically presented as the customer needs driving the product focus distilled from both qualitative (eg. customer feedback) and quantitative (usage data) 3. Helping the team understand the market landscape - This is presented as the market the team's product is targetting, competitive offerings in the market, strengths and weaknesses of the competitor compared to your product's strengths and weaknesses. 4. Mostost importantly, helping the team make decisions when they have incomplete information through rigorous logical reasoning and trade off analysis. Identifying the level of risk in the decision and getting buy-in from right level of leadership (higher risk requires a higher level leadership to sign off on the decision). 5. Finally, making sure the team is not revisiting a decision made in the past unless some new and compelling information surfaces that makes it a no-brainer to change the previous decision. This typically involves helping the team document decisions and clearly articulating the rationale for the decision. At Atlassian we use the DACI framework extensively for this purpose. As you can see, a PM can do a lot to influence decision making without actually being the person to make the decision. In the few instances where the PM has to be the one to make the decision, it's worth thinking through the worst thing that can happen if you got the decision wrong. You will realize that the stakes are not as high as we make ourselves believe. I like to remind myself that no one's life is at stake if I made a wrong decision, after all I'm building a collaboration software and not a critical medical equipment. It's also useful to remember that you make a lot of decisions in day to day life without breaking a sweat. Why should product decision making be any different?

Collaborating with Product Marketing is a key part of any product's success. In smaller teams/companies, that role can fall on to the Product Manager directly, whereas at bigger organizations that is a more dedicated role. I am fortunate now at Cisco to have access to some of the best product marketing resources in the business. The work that we do together from product strategy, execution planning, and external marketing helps ensure our business objectives are met and made visible within our specific market. We work closely throughout the GTM process and fostering this relationship is one of the key components to a solid product launch.

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

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.

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.

Great question. In my personal career journey as well as several hires I’ve made I’ve always found it helpful to try the new role before you go all in. When I was at a startup where we didn’t have well defined programs like Google’s 20% program or PM rotations, I asked to work with the PM team for 6 months on the side where I took on some of the PM responsibilities for a non-critical product. By doing so, I personally got conviction if the role was right for me and the PM team also got to see me in action. This made my transition much easier and also helped me come in at a more senior role. Similarly I’ve made hires who had a similar path - they often either did a 20% project or a full time rotation - and this helped make a case for their PM transition. If your organization doesn’t have formal programs to try the PM career path I’d encourage you to network with PM leads you are close to and see if such a project could be developed.

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.

* Ownership of a key business metric/s: Almost all head of product roles involve ownership of one or more key business metrics. * Cross-functional partnerships with experience of successfully managing up: As PMs grow in their career, it becomes critical for them to identify the right cross-functional partnerships for their teams, align on common goals and outcomes, and inspire their teams to accomplish said goals. It also includes building skills to manage-up by ensuring C-Staff/leadership visibility on the most important projects or initiatives their team is driving, building a business case to get the required funding/staffing for it, working with their teams to drive the project, unblocking the team as and when required and ensuring that the outcomes are well communicated to create confidence in the next project/initiative they undertake. * Asking the right questions: As HoP, you will most likely not know the details of either the problem or the solution your teams are working on. Plus, you will make multiple context switches across various critical initiatives throughout your day. Hence, it's important for you to ask the right questions in the limited time you have to get a good understanding of what your team is working on, such that when you are asked to make certain decisions, you have enough context to make an informed decision. * Mentorship: For HoP roles, it's important for a hiring manager to know that you can inspire and lead your teams. Skills in managing high- and low-performing PMs, inspiring PMs and teams around an important but difficult outcome, and mentoring PMs and/or other team members can describe a HoP's skills in this area well. Previous experience with anecdotes specifically addressing the above skills can help candidates in interview settings.

There are lots of frameworks, templates, and communication channels you can use to create ongoing communication about past launches. I usually find the biggest issue with this type of communication is not a lack of framework or tools, but usually either (1) remembering to do it or (2) keeping people’s attention post launch. For remembering to do it, I would just set calendar reminders for yourself and hold yourself to it. That is what I personally do. For keeping folks' attention, I would suggest starting a cadence of regular updates BEFORE the product launches - then you can get people into a rhythm of updates. They will know when and where to expect the information. Then once you get past launch, you can adjust cadence but keep the content and the channels the same con continuity. This can help people to have a mental model to receive this info, even well past launch. A framework that I like to use for these types of updates is: wins, learnings, next steps. This is a good way to keep people focused on the impact of the work, and may also encourage more attention if you are good at highlighting learnings that can be shared more broadly with other teams. 

This isn't easy and many companies, including Hex, are looking for domain expertise to maintain a super high velocity in driving value for users. Learning a domain takes a lot of time. However, there are things you can do to be a more effective interviewee when you don't domain experience: * Demonstrate strong fundamental product skills (focus on the why and the outcome that you drove). * Practice your interviews and come with strong preparation and communication. Focus on the effectiveness of your communication. * Do your research on the domain and the product and demonstrate an understanding and a perspective in your interviews. Always use the product in advance of your interviews and apply your product expertise to identify hypotheses of strategic shifts or UX improvements that you'd consider if you were to take that role. Talk to product users to understand their current pains or read reviews or online forums to understand the user perspective. * Explain and show your passion and enthusiasm for the new domain that you're trying to crack into. Proactively address why you want to shift domains.