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?

In my mind, it's not an either-or. By growing existing talent, you retain organizational knowledge and build a shared culture, while bringing in external hires inject fresh perspectives and sometimes specialized skills lacking within a PM team. When I am looking at my team structure and needs, I often consider the following: Things to Consider: 1. Internal Development Programs: Promote from within by offering training, mentorship, and rotational programs that broaden your team's exposure. This approach (in my experience) strengthens loyalty, develops institutional knowledge, and keeps your product strategy consistent. 2. Hire Externally: Often times PM teams get into stuck patterns and fresh perspectives are invaluable for a team's growth. When I need new capabilities, like a strong data analytics background, or experience in a specific market segment, hiring from outside will usually shorten the learning curve and bring proven experience to the team. This ultimately helps the broader team as their exposure to these new skills raises everybody's value and potential. 3. Do Both: We need to do both internal development and external talent acquisition to manage the best possible team. Keep growing your internal team by providing new opportunities and challenges, while selectively recruiting outside talent to fill knowledge gaps and bring in fresh eyes. This way, I keep our internal culture strong, ensure continuity / grow loyalty and still gain a fresh perspective when you need it.

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

The following stand out to me for what I've witnessed: * The team is acting like the product they're creating is going to be successful. I'm amazed at how many successful companies try to build new products like they do for their existing successful ones: same processes, same success metrics, etc. They don't have the urgency, move too slowly, learn too little, are complacent. The market is a graveyard of failed products and businesses: the most likely outcome, when creating a product, is that it will fail. As a result we shouldn't assume success but instead focus on doing everything we can to de-risk, test and validate - and make sure we don't over-invest too early. I recently was interviewed in Lenny's podcast to talk about that: if you're working on 0-to-1 in a bigger company I think it's worth your time. * The team built a solution to their own problem and they assumed that many more people would face it in the same way. We hear a lot of success stories that started like that, and while it's true that some successes began like this, it's also where a lot of failures came from. You're not the customer of your product: work with real customers! Or it's only going to work for a small population, and that may not make it a viable business. Mehdi, the founder of Cycle, shared openly a great example of this for how they changed their approach to user onboarding. * The product manager tries to get a big team from day 1. Honestly a small team can move 10x faster than a big one. You need a team of people you can trust who can move mountains on their own and continents together. For the first year of creating Jira Product Discovery we only had 5 engineers, and we moved really fast. It forced us to focus on the most important things, to be nimble and creative when testing solutions, and we could do this with very few meetings (it's very easy to get everyone on the same page at that scale). Once you've proven you have a solution that solves real problems for a small number of users - you can then go back and ask for a (slightly) bigger team. Resist that urge to grow too fast! * The team is fighting too many battles at once. This happened to us at Atlassian when we tried to rebuild Hipchat into another product called Stride. We were trying to launch a new product built on top of a new platform that could be used for all other Atlassian products. We faced this tension product<>platform from day 1, and it was much slower to move on the product front. Like with any failure there's of course more than one reason this product didn't pan out, but this is definitely one of them. * The PM fails to get the right level of buy-in internally - if it's about creating a product inside a bigger company. It's very important to "build chips" in the company (gain trust from leadership) so you can spend them, gain more chips, etc. And it's key to communicate your learnings and progress in a way thatmake your team look like a high speed train - no one wants to get in front of a high speed train. This is one of the topic I cover in an interview on Lenny's podcast.

* 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.

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.

In qualitative research, there's this practice of converging, mapping, coding, and providing themes of your research participants' narratives or transcriptions. In that convergence exercise, you are aggregating these insights for high-signal findings and themes. As a result, there's typically going to be enough critical mass in a particular area for you to create a theme or a particular insight. If you're finding that you're getting a lot of conflicting information or you're not able to establish a theme, this may mean you need to look at your participants. Analyzing if their roles are mapping to the problem that you're looking for. Sometimes when you're getting that convergent insight, it's because you're not targeting the right audience. Ask yourself is this participant is from the right company, industry, or experience. Is the segment correct? Is the company size correct? Is the role or persona correct? And after you refine that, you might need to expand the number of participants per role, and then you may have different insights per kind of cohort. This difference in cohort insights is a natural part of research. You'll learn that different users and different personas are going to have different needs in your product. So if you're interviewing, let's say, an admin persona who's responsible for setting up a particular product versus an end-user persona who's going to be interacting with the product, they're going to have different expectations of what a product should do, and therefore your insights are not necessarily going to be the same.

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.

It can be difficult to change companies AND domains in one step. I would advise you to consider the possibility that this may be a two step process, where you focus on changing one variable at a time: 1. Change companies while keeping domain constant. 2. Change domains once you are internal and you’ve built up enough credibility. Ultimately, it is up to you what you are comfortable with. Personally, I have found gradual transitions have allowed me to achieve greater success at each stage.

It depends on the roadmap that we are building. There needs a balance of both. The Big bets are more the innovations that will help do a leap frog. Given significant investment here, this is usually vetted with multiple stakeholders. The incremental innovations are another way to accelerate the speed of delivery and help course correct quickly. This is something that I use more for quicker delivery and validation. Sometimes these also are build with partnerships across multiple design partners