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?

Great question. It's really hard to prioritize small, iterative product improvements against large new features/bets. In my experience you need both, as well as a few other aspects. The way we do it in my teams is to think of it as balancing investment levels between different buckets, and to dedicate capacity to each of these buckets. Otherwise it's a constant struggle. We've tried to describe it in this section of the Atlassian product discovery handbook talking about ideas, and that one about prioritization. A couple of different types of buckets: * Boulders, rocks and pebbles * Boulders: large investments with potentially big payoff but high uncertainty, too. E.g. one or multiple teams over one or multiple quarters. * Rocks: medium sized investments with fewer risks, but potential for delighting users. E.g. one team for a month. * Pebbles: Small, typically straightforward change. E.g. one person for a week. * Don't underestimate the impact of rocks and pebbles! In my experience users LOVE to see the app they use get better every time, that's a great way to create fans. * RUF: Reliability + Usability improvements + new Features. Think of the RUF framework as a pyramid: * At the base of the pyramid there's Reliability. Reliability is about building trust. Trust takes a long time to build, but can be destroyed very quickly — a single event of data loss or security breach can be a serious source of churn, let alone repeat incidents. So you need to invest in your product's reliability first and foremost. * Usability Improvements comes second: a feature is rarely “done” — it’s part of a system and that system needs constant tuning. In your roadmap, it is important to allocate budget and resources to keep investing in improving your current feature set. * At the top of the pyramid is new features, both large and small. Then you decide how you want to invest in each: E.g. for a super early stage app you might be spending all your time on boulders and rocks, and little in reliability or usability improvements. For a more mature product you might spend 50% in the reliability bucket and only 10-20% on new features. Then how you actually implement that in your team can vary. In my teams we look at it at investment over time: we might be focusing on a boulder for a quarter, then go back and tackle a few rocks and pebbles. Some of the teams have a rotation where 1 engineer is focusing on pebbles each week. etc. But the important part is to have a strategy and make it a conscious choice, vs something that you react to every time you get a new request from a customer or stakeholder.

This one is fairly easy, add value. We as Product Managers need to ensure that we are adding value for our organization by understanding the market (and our customers) and guiding the strategy to be successful in that market. It's easy to be a product expert, but we need to focus on being market and strategy experts. In my career, some key examples of adding value are: 1. Knowing My Market Better Than Anybody Else. When I am the expert on what our market needs, both short and long-term, I add significant value in defining and driving our strategy. My product can't be successful without this. When we are proven right in terms of our strategy definition and market validation, we win. 2. Build and Foster Relationships I work hard at establishing relationships around the organization where I am working. These enable me to be effective in cross-team collaborations and makes driving alignment across the organization easier. My relationships add value to me and my team. 3. Be an Expert When you are viewed as an expert and continually show your expertise in an area that is needed within the organization, it's easy to be seen as somebody who deserves that promotion. Show that your expertise drives direct value for your organization with clear successes.

Love this question. User research is critical to incorporate throughout the funnel journey for a PM - from awareness, to consideration, to decision. * Awareness: During this phase we want to understand how prospects are learning about your product. For example, do they resonate with the messaging and positioning on your website, do they understand the market you play in, do they understand the problem you are looking to solve? This type of research can be conducted often at trade shows, through surveys, anonymous interviews, new generative AI tools to look at user review, and other marketing driven & community events. In the case of PLG products - data can play a critical role. For example what was the click through journey of your prospect, which pages did they spend the most time on etc. * Consideration: During this phase we want to understand what type of buying decisions a prospect is considering in the purchase of your product or new feature. This is often the most difficult to do direct research on as it can be hard to identify when a prospect is in this phase. I find secondary proxies here who are interacting with your prospects in this phase extremely valuable - for example the sales & sales engineering teams, & channel partners. * Retention: Once a prospect has purchased a product, this research helps us understand what will help a customer retain usage and expand footprint. Example forums for this type of user research include small customer advisory boards, private preview feature feedback, UX design sessions, customer success & support manager feedback, user questions & trends on online support communities. 

Product Manager position could be optional. A team building a software product will have someone fulfilling a product manager role either way. * Who will take accountability for the market success of team’s work? * Who will deeply understand the market, the customer and their pain worth solving? * Who will fight for the team inside of the organization to acquire needed resources and to defend existing? * Who will be a “PR manager” building team’s brand inside of the organization? * Who will detect early learning and make a case for adjustments and improvements? This list may go on and on. Try to make the case not for the position of a PM (“I am a PM, you listen to me”), but for the inevitability of the work above for any successful team. Chances are, your engineering leader and their team do not find this type of work most exciting. Hopefully they are reasonable to agree it is required, or at least helpful for the eventual market success of your product. From there, if you established there is work to be done - demonstrate how you can take this work off the team’s plate and have them focus on what they do best and enjoy most - building great software (or hardware, if that’s your thing).

This is somehow the simplest and toughest question on here 🙂 Your typical PM career path can look like: * PM: Responsible for a KPI or set of features * Senior PM: Responsible for a product area end-to-end * Staff/Group PM: Responsible for a product end-to-end * Principal/Director PM: Responsible for a business unit * VP PM: Responsible for multiple business units * CPO: Responsible for the entire Product org ...but I personally don't find that framing helpful because it varies so much from company-to-company and there are many factors that would make me hire a Senior PM at company over a Director at company . So, here's an alternative approach to thinking about a PM career where each stage could span across multiple titles depending on the maturity of the org: * Deliver at a high velocity: Ship! Ship! Ship! Build the muscle to take things from idea to product and do this at an insanely fast pace. * Learn to love the craft: Now that you've built the delivery muscle, master the details of your craft. Assess other products through a keen eye and try to discern what differentiates a good product from a great one. Learn to care about the details, since it's as important as the high velocity. * Be a driver for your product: Go beyond your feature or product area and think about the entire product. Familiarize yourself with the P&L, revenue drivers, GTM motion, and try and identify opportunities to improve customer value and ARR for your product line. * Be a driver for the business: Do ^ but across products for the entire business. This also involves identifying opportunities for new P&L lines through product innovation.

Market trends can be a good indicator of what will matter to users, investors or stakeholders. Don't ignore them, but also don't let them distract you from the fundamentals. * Do you think this trend will drive a permanent shift in the market you operate in? If so -- consider how you can position yourself for success in the long term and the pros / cons of investing in alignment. If not, consider whether there are short / mid term changes you want to make to take advantage, or whether you just want to ride it out. * Identify where the trend is coming from. Is it driven by macroeconomics? A technological innovation? And are you and your org well positioned to take advantage of it? * Are you moving early enough vs other competitors? If you have an opportunity to be out in front of the crowd -- can you position yourself as a leader in this trend and drive marketing value from doing so? * Does it genuinely drive economic advantage for you, either directly or by second order effects?

Setting a fast-paced rhythm and providing predictable touch points are the two practices that a product manager can heavily influence that can impact team velocity. These two concepts are related: a rhythm gives teams in your organization a common pattern they can align to. Everyone knowing that the team operates on sprints of the same length, with a common calendar, how decisions are made and communicated in a common way, a clear way drivers, approvers, and contributors are determined and documented for projects - all feed into a sense of rhythm and predictability. I call out predictable touchpoints specifically because they provide some level of control on the thrashing that organization leadership can inadvertently cause when interfacing with the team. By setting the touchpoints at the various levels of leadership in advance, and providing clarity on what will be reviewed and decided at each touchpoint, its easier for the product manager to isolate which areas of the team may experience change and keep other teams more focused. Lastly, it's important to work with your engineering and design counterparts to keep a constant investment in agility operations and tools. The faster each discipline can do their daily tasks, the more agile the overall team will be. This can range from providing time for developers to adopt AI code generation tools, optimizing a CI/CD pipeline, resolve long-standing operations issues that are costing time, and so on.

We first absorbed all the relevant user research available, spent a ton of time with the core PMs to understand what had been tried – what worked well and failed. We also, in parallel, looked at data and business trends with the core PMs and assessed not only biggest areas of impact but also areas that potentially had low hanging fruit – all of which were aligned to our top user needs. Aligning the vectors of the growth team with that of the core product organization, leaning on the wealth of knowledge that already exists is critical to initial success. Our biggest challenges in navigating the shift: * Data instrumentation and proof of direction – It takes a bit to get the new KPIs off the ground, especially when it comes to engagement loops. What should the KPIs be (e.g., what is the setup/aha)? How are they correlated to business impact? How many KPIs do we prioritize this qtr.. this year? This takes a good few months to establish and prove out. * Overall dynamics – setting up the growth squads needed for success – the necessary number of engineers, designers, data scientists, PMs… especially in years when resourcing is not easy to come by is the hardest part. This requires constant discussions (read negotiations), operational efficiencies and ruthless prioritization.

This is the best question to start with! Objectives and Key Results are often praised because of the stakeholders’ expectation of clarity, alignment, and clear/standard reporting. OKRs are often hated by teams because of being badly defined, in a way that misrepresent success or progress, and get costly to update with little meaning. Before going into details it’s important to note that there is often confusion between Key Results (KR in OKR) and Key Performance Indicators (KPI). While both are meant to be a single meaningful number, KR express progress towards an objective, KPI express a behaviour of the business or market that might not be related to an objective (yet!). As such a KR is often a leading metric (progress toward a future state), KPI is often a lagging metric (observing the result of various past dynamics). For OKRs, Objectives are usually easy to come by, but the core of OKRs’ success are good Key Results. The best Key Results have those characteristics: * Concise to communicate succinctly and efficiently horizontally and vertically, * Reflect incremental progress (ideally evolves linearly from starting point to finish line), * Are leading metrics (can be updated as we progress towards the goal), * Meaningfully targets a successful milestones towards the Objective. Here are a few examples of Key Results I have been using in the past: * Example about fixing a situation expressed as a percentage from current number to future number: Bring quality issue resolution turn around time to matches [product] median [at target number] by [date] * Example about ensuring consistency expressed as a percentage of total delivery over the period: Deliver [product] roadmap updates to the community [at frequency] during [period] * Example about a single delivery broken down in somewhat equal phases or deliverable: Deliver sales enablement material for [product] for each [identified categories] by [date]. * Example of an exceptional case when a KPI has a lifecycle so short it can be used as a Key Result: Turn community sentiment towards [product] from [baseline] to [target] by [date]. See question “What are some of the worst KPIs for Product Managers to commit to achieving?” for patterns to avoid. See question: “How do you approach setting crisp KPIs and targets for Engine features and linking them to your topline metrics?” for my step by step process for realistic OKRs.