Narmada Jayasankar

Very relevant question for the times we live in. I'm going to focus on how PMs at Atlassian are using AI to augment their workflow, since that has been a huge focus for us. 1. Refining your writing - Atlassian has a very strong written culture, especially within the PM team. This how we communicate ideas, strategies and influence stakeholders. It's no surprise that we leverage Confluence very heavily and the AI features help PMs go from rough draft to a polished document pretty quickly. 2. Consuming written communication faster via AI summaries - the flip side of having a strong writing culture is that you now have to consume a lot of written documents very quickly. AI driven summaries integrated in Confluence, Rovo Search & Chat are time savers. 3. Creating prototypes from PRDs - most of the time a PM spends with their teams is to drive clarity on what needs to be built and why. AI Tools like Bolt, v0, Lovable and Replit enable PMs enable PMs to quickly convert their PRDs into a working prototype without having any design or coding skills. It's way more efficient to align your team using a prototype rather than a written document (PRD) 4. Rapid iteration - we all know that testing prototypes with customers is a great way to validate ideas before writing any code. But it still take significant effort and know-how to create prototypes and iterate on ideas. Changes are made between user testing sessions rather than during the session. Prototyping with AI significantly shortens the time and effort that it's possible to make changes to the prototype during the user testing session with just 1 or 2 prompts.

It's hard form be to give specific advice to you without more context about your situation such as who is assigning these tasks to. Is this your manager? If yes, my first thought is, does your team / organization understand the value product managers bring? Is there a strong focus on product management craft? If the answer is no, then you have 2 options 1. Try to build an understanding of the product management craft within your organization. This only works if you are sufficiently senior in the organization (or the organization is smaller). 2. Move to an organization that has a stronger understanding of the product management craft.

In my opinion, building influence with your engineering team boils down to these 3 things 1. Understanding engineering complexity even if don't quite grasp all the details eg. do you understand the cost (experience implications, impact to future team velocity etc.) of having tech debt when you ask your engineering team take short cuts? 2. Being able to represent the engineering considerations in forums where your engineering team is not present eg. discussions with the sales team where they ask for specific delivery dates features on the roadmap. 3. Empowering the engineering team to understand the product context and take shared ownership for outcomes rather than just being a delivery team. A good litmus test for this is to assess how comfortable your engineering team feels about making product decisions and keep making progress when you are on leave. If you invest time and effort in doing these 3 things, you will build significant trust and influence with your engineering team.

Here are some of the common mistakes I've seen (and done!) PMs make that results in not getting buy-in for your roadmap 1. Not aligning on the outcome explicitly - What is the outcome (Revenue?, better customer experience?, Faster time to market?) your are driving with your roadmap and is that clear to your stakeholder? Is your stakeholder aligned on this outcome? If they are not, then the buy-in for your roadmap means nothing because there will be misalignments on many decisions you will need to make as you execute your roadmap. 2. Not communicating the principles and constraints that drive prioritization of your roadmap - The factors that influence prioritization may not be obvious from just looking at the items on the roadmaps and the stakeholder may not have the same context as you do. So, what is obvious to you when looking at your roadmap, will not be obvious to them. 3. Giving the impression that your roadmap is not changeable - nothing frustrates a stakeholder more the feeling that they have no influence over your roadmap. You should give them a chance to have an input into your roadmap before your roadmap is finalized.

While project management and product management require similar soft skills (communication, negotiation, structured approach etc.) there are some fundamental differences. For instance, project managers need to be risk averse because their job is to make sure projects are delivered as promised. Whereas, product managers must have a higher risk appetite as their job is to maximize outcome for the business and must explore unconventional paths get to the outcome. So it's important to recognize that these are fundamentally different jobs and approach product management career with a sense of curiosity. Other than, the approach to getting into product management is the same for people transitioning from any other craft. The easiest way is to find product management opportunities within your current team / organization, rather than job hunting in the open market, because they already know you and your work.

At every level, the core PM competencies of driving clarity and alignment through clear communication, delivering measurable outcomes for the business and influencing without authority remain the same. But the ambiguity within you are required to clarity, the impact of the outcomes you drive and the seniority of the stakeholders you influence increase as you become more senior. If your are a people manager, the size of the PM team, and the diversity of PM roles within the team, increases as you become more senior and you will need to start thinking about strategies to grow and retain talent at scale. In a nutshell, it's the same core competencies, but you are expected to operate with greater ambiguity, deliver greater impact and have broader influence commensurate to your seniority.

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?

I have a strong bias towards data-informed approach over a data-driven approach as I believe that data is just one of the many inputs that product manager needs to consider for decision making. There will also be many situations where you will need to make decisions when data isn't available or it's imperfect. In some of these situations, you may not have the choice to wait for data to become available. So, you need to be able to leverage your intuition to make decisions and keep making progress. Another interesting aspect to consider - while data feels very black and white, in reality it is not. The same data can be interpreted differently in with different context. Unless the data you collect follows a thorough and rigorous process to remove all bias, the interpretation of the data can vary. As you get more senior, the situations you are dealing with are more ambiguous (i.e. perfect data is almost never available) and waiting to make decisions is never an option. So, data-informed decision making is the primary operating procedure.