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?

No-one can, or should ever be sure that they have a 100% right product strategy. But you can do a lot to de-risk your approach, and your tactics should vary depending on how much time you have to plan. * Is your strategy ultimately going to drive the change in behaviour you want? Find the key participants in your strategy -- e.g. the customers -- and talk, talk, talk to them. You'll learn a ton from the first 5-10 conversations, and suddenly you'll start to hear the same themes and be able to predict what they'll say. Then you can move on. * Read, and connect with people who are familiar with this situation in your industry or other industries. How did things work out? Is the current market / environment similar enough that you can draw conclusions? * The more experienced you are, the more confident you can be about relying on product intuition. A phrase I often use is "we've seen this movie before" and, it's surprising how many times the same situation gets repeated.

PM work life is a firehose of Slack/Teams message, customer emails, meeting requests and deadlines. Here is what I find helpful to make sense of the chaos and stay on top of the key things. * Capture, Organize, Get Shit Done. Resist the urge to jump on every message or email the same moment - you may find yourself exhausted while still behind on your goals. Instead, find a tool which lets you to quickly “capture” a thing which require your attention - and move on. Organize these to-dos thoughtfully - later, when you have time: what need to be done now, today, later this week? Some people find Eisenhower matrix framework helpful, though it may require much discipline and self-training to apply it to every day situations. My personal go-to solution for capturing and organizing PM to-dos is Trello. * Meetings. Look at your calendar and brutally question it. Which meetings you don’t have to be in? Which ones you’d be fine just reading a summary after? Sometimes you’ll have to say “no” to get your work done, even if it slightly annoys someone. * Async collaboration. A great way to reduce meetings load for me is Atlassian Loom: record a short video clip and share with your collaborators, let them responds or even with another video clip, async, at the time which works best for everyone! * Focus time. Every week you likely have a Big Rock - a bit of work which isn’t immediately urgent, yet have an outsize importance and require significant focus time to accomplish. * Plan your week. Apply everything above to your Friday routine - plan your next week ahead. Meetings you’ll decline? Focus time you’ll block on your calendar - to accomplish most important tasks? 3 things (maximum) you are looking to accomplish next week? * Plan your energy, not time. Lastly, recognize when you are at the peak of your productivity - late afternoon? mid-day? morning? Do your best to allocate this time to the most important things you are looking to accomplish. You are most productive on Fridays? Make it a no-meeting day to finish up that blog or product spec!

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.

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.

* Ability to get up to speed on unfamiliar, complex areas quickly * Highly reflective on past experiences and deep growth mindset * Infectious curiosity about customers * Succinct communicators, verbal and written These are some of the most difficult qualities to coach, and become more difficult to coach the more years of experience the person has, in my experience.

PMs are able to help engineers with: * talking to all different types of customers and prospects, so that we constantly have informed/holistic insights into most impactful problems we should be solving for our target customer * taking the set of problems we have to solve, strategically sequencing them (roadmap), and pitching this to leaders internally to ensure buy-in + resources to fund this work * take the lead on solutioning - working with engineering, product design, content design, user research, and data science - to ensure that we are building a feasible/impactful solution for the right problem * evangelising the products that we are building and collaborating with GTM stakeholders (Customer Success, Account Executives, Solutions Consultations), pricing teams, business development, legal, product marketing - so that the product is not only built, but well-loved and highly adopted by our customers * and so many more things Engineering leaders could drive all of that, and they are capable to. But oftentimes they are focused on managing large organizations of engineering staff and driving technical/architectural vision. And good PMs have years of experience and training on this work specifically, as opposed to having to focus on people management.

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.

You should be thinking of your product management career as a story and be thinking about what the headlines and chapter headings for each one of those stories is. What are the sound bites of the things that you accomplish in each chapter of your career journey? Those should be big and progressively getting bigger as you get more senior. For example * Tripled SaaS revenue over two years from 25MM to 75MM. * Grew the size of the product management organization from 5 to 15. * Won Gartner MQ 3 years running * Eliminated $12MM in opex, leading to GM improvement from 8% to 12% and putting us over the rule of 40 Thinking about those metrics and planning them out will allow you to tell a story throughout your career that shows increasingly bigger outcomes being driven on bigger scales. I can tell you that when folks call me for executive jobs, what they are typically asking, and I think this applies for any people management job and product, the scope of responsibility that you had. And typically that's measured by number of reports in your organization and the rough amount of revenue that you drive. That's what folks care about for directors, senior directors, VPs, and CPOs. So the sooner you can start to be thinking about, okay, how are those headlines going to reflect my ability to increase the size of the revenue we're doing, the market we're capturing, and the business outcomes delivering, the better.

To build up the best Objectives and Key Results, I usually ask the Product teams to follow a yearly schedule of strategic planning (aligned on fiscal year, ideally also aligned on performance review cycles). This is aligned on the basic scientific methodology. Q1 define business hypotheses (observation, question, hypothesis) This exercise starts with refreshing our predictions about the long term state of the market based on ongoing trends. We then look at how to fund in the medium term our path to successfully get to the long term target. We do this by going over the categories of customer acquisition, retention, share of wallet, market shares, customer costs, customer success, customer satisfaction, brand value, and express targeted business hypotheses. This could be revenue, user behaviours, competition numbers, specific required features for the engine to serve evolving needs… Q1-Q2 validate/invalidate business hypotheses (experimentation, data collection, analysis) We spend the next phase of the fiscal year diving deeper in market research and data collection/analysis to try to validate or invalidate our business hypotheses. As we increase our confidence in identifying precise problems worth solving, we put together business cases to pitch strategic investment adjustments to senior leadership. Q3 define strategic initiatives (conclusions and communications) Going into this phase we start gathering support across senior leadership for the various business cases we built, find sponsors, and pitch those in the context of defining strategic initiatives for the next execution cycle. Those business case contain a clear set of success criteria in the form of metrics that meaningfully illustrate achieving the business outcomes of the business case. (See literature on outcomes vs outputs). Q4 adjust organizations for execution Once strategic planning is complete and senior leadership is aligned on those initiatives and their investment priorities, they usually design changes to the organization to set us up for successful execution. The Product Management team would at that point draft OKRs and start reviewing those with the updated leadership team. Those OKRs are most of the time Objectives representing the desired goal for the business outcomes described in the business case, and the Key Results are chosen for their ability to be realistic to collect and meaningfully represent progress. Rinse and repeat (iterations) At this point the organization is setup to execute with clear priorities and goals and Product Management can restart the cycle! See question: “What are good OKRs for product management?” for guidance on shaping good OKRs.