AMA: Atlassian Head Of Product Management, Confluence Experience, Natalia Baryshnikova on Developing Your Product Management Career

Two ways. First sweet spot is to pick a mid-size startup (round B or C) that is growing. They need folks all the time, and they need folks who can roll up their sleeves and do things. The roles you join in does not matter as much - if you prove yourself as a doer, you can later transition into a different role, such as PM. Second is to look at established product orgs that have an APM program (we do have one at Atlassian!) This path is more suitable for recent grads that are embarking on a career journey. If that is you, search for "APM programs" and read up on which ones resonate with you, and apply.

Ultimately, prioritization comes down to a chain of decisions. Regardless of the framework that you use, the question I see folks overlooking a lot is "who is the right person to make this decision". Is that you, the PM? Is that your manager? Or maybe, if the work relates to security vulnerabilities, is that your VP of Engineering? At Atlassian, we use the framework named DACI for all decision making documentation: https://www.atlassian.com/team-playbook/plays/daci The great thing about DACI is that it helps you align on whose call it is to make something a priority. You would be surprised how often top management expectations turn out to be just suggestions, whereas top managers will want you, the PM, to make the final call as an Approver in DACI terminology. My recommendation is to make draft prioritization of backlog using the framework that suits you, but be very diligent about whose call it is to prioritize something, and be proactive in communicating that to management and other stakeholders. This way, you will separate really critical items that may get prioritized based on someone else's decision making power from things where folks have just opinion, and ultimatley want you to decide.

First thing I'd recommend is asking your team if there is a formal description of levels and skills associated with each level. More and more companies, whether large orgs or startups, actually have written descriptions of product manager levels and what those entail; the earlier you get to learn about them, the better. If there is no formal description available, I would recommend to: 1) Interview your manager of what the next level may look like, and draft a document outlining that 2) Review this document with 1-2 people in the product org who are on that level and see what they would add. If there is no one in your own org, venture out and ask folks from other companies what is typical in their orgs. 3) Review the updated document with your manager again, and make a growth plan for each skill, milestone, or attribute of the next level. It may look like this: "Product Strategy: be able deliver and present a product roadmap for area X to executive stakeholders". 4) In growth plan, outline speicifc milestones (e.g. a succesful review of product strategy) and timelines (e.g. in the next 6 months). 5) Set up a recurring review of the growth plan with your manager (different from regular 1-1s). The above may sound like a lot of work, but figuring out what skills you need, and proactively approaching your growth will pay off for you. 

The biggest struggle I have observed is related to transition from an individual level product craft growth to growing that of a group. Andy Grove in High Output Management said "Managers are responsible for increasing the output of their organizations and neighboring organizations they influence". Read this sentence again and again. The learning curve is in learning how to optimize for the outputs of your team vs. your own. This means that you need to make trade-offs across your teammates and their areas, as well as help each of them grow as much as possible. My recommendation is to read up on team management in all contexts - business, military, sports have great writings on it; there are also many articles and videos from leaders of all kinds. Then, ask yourself (before you were to manage a team), how would I change my prioritization frameworks, rituals, interactions, communication style if I were to optimize for an output of a team of PMs. You can even hypothsize about it using your existing team - if you are a manager tomorrow, what would you do differently to optimize for the greatest output? Simply thinking and writing your thoughts down on this topic, as well as honing in on skills I mentioned above in the "director level" answer should help you prepare for the transition. 

1. Storytelling. You need to be able to tie many disparate pieces of product work - user needs, business goals, technical limitaitons, competitive landscape, innovation opportunities - into a coherent, compelling narrative. A director can fill in the blanks in the following sentences with ease: "This year, my team is trying to achieve _____ because our comany needs to _____. In order to reach our goal, we need resources of ______ , focus on ______ and ______ and support from ______." 2. System thinking. A common mistake I see in PMs is trying to get *their* work done without thinking through the impact it has on adjacent teams - think, I need to meet MY goal and have MY feature on the home page, without consideration for a global optima. Directors need to think at least one level of abstraction about their own area. Who else will be impacted by your work? Is that impact good? Does it add up to greater good, or is it a local optima? 3. Inspire others. The difference between a manager and individual contributor PMs is that the goal of individual controbutor is to "get sh*t done", and goal of manager is to "make sh*t happen". You need to be able to achieve goals through your own work AND the work of others on your team. This is only possible if people can be inspired by your vision, integrity and leadership. 

First thing to do is to check with your manager how they think about your growth. They may be thinking that they are helping you, and it is just your perspectives that are misaligned. Ask them about their definition next level of growth for you (see answer above about growing skills for details), and then ask them how are they planning to invest in your growth - have they considered additional opportunities, challenges, projects to give to you to help you grow? If the result of the above effort does not result in a clear growth plan with a commitment from a manager to invest in you (it's their job!), consider switching. If that is you now, we are hiring a lot of PMs at Atlassian, and work diligently on building growth plans for all of our PMs :-)

Startups are all about speed. To move fast, you need to know where you are going (aka what to be ruthlessly focused on) and allocate the most of your time/energy to that. Easier said than done, right? One thing that helped a lot in my early startup days was my framework of "One thing I am going to fail today". Once you establish together with your team what you are focused on this week, month, quarter - write that down and look at it every day when planning out your work. Then, notice things that either don't help you move there, or things where your quality of deliverables will not be critical to the area of focus. Then, tell yourself (and the team, if you so prefer) - I am going to focus on nailing X today. I will do an okay job on Y, and I am going to drop the ball (or fail) Z. Breath out, and go stay focused. 

There are three aspects to selling this well: 1. Empathy. You have to start with acknowledging the validity of a need or ask. Folks often skip that step and go straight to rebuttal. Don't do that - you need to empathize with the stakeholder, understand where they are coming from and really ponder a possibility that their ask may be a good thing to do. This is how you build trust. 2. Narrative of why not. Built upon the understanding of the stakeholder need above, you need to develop a crisp and compelling narrative about why not now. This usually works best when you can appeal to a more urgent business or user problem you are solving, technical considerations and so on. Important is that it needs to make clear what you are optimizing for in saying "not now" and give good reasons as to why. 3. Courage. Another common pitfall is avoiding to have a tough conversation with a disappointed stakeholder. People are used to hearing a "no" in the product context a lot. For top managers in particular, it is also really hard to distinguish when they are just expressing their one-person opinions vs giving directives. Keep that in mind, and communicate your "no" firmly and early. Don't keep promising to "look at it later" if you know you won't.

See my answer above on breaking into tech as a PM for one of the options. Another option, if you are a mid-to-senior career professional is to build ties with your product team internally. Product leaders need good folks all the time; I have facilitated multiple secondments of folks from other departments into product, that resulted in a successful full-time career switch for those PMs. Chat with folks in product leadership in your company, and ask them what would it take to have a secondment on their team. You may need to hustle a bit to make it happen, but most people will be willing to hear you out and considering making your secondment a reality. From their, it's all about your execution. Good luck! There are many talented PMs out there who switched careers, and you can do that too!

Will add my favorite question to ask the managers of product managers (GPM, Director and above): "Tell me about a product manager you've worked with, and who's better than you and inspires you. What about them makes you say so?" Best answers usually involve leaders speaking about people on their team (reports etc), or someone more junior than them who they helped grow. If someone has been a people manager for a decade or longer, and they have never had a more junior person on the team who's better than them, this makes me probe more into their ability to lead, recognize talent and be humble enough to see that someone has better craft skills than they do. As a leader, you are guaranteed to have to lead people who are smarter, better and more talented than you. Having the humility to recognize that and work with it is key to scaling as a product leader and being able to attract and retain talented folks.

"Assume I don't know anything. Teach me something in the next two minutes about a topic you are passionate about - can be anything". This questions helps me understand how a person thinks on their feet, does storytelling, and uncover more about their passions as a human, that may have some interesting overlap with product work. I have learned how to swing a gold club, calm down crying toddlers, and pick soil for any plant from asking this question.

At Atlassian, we look at multiple pillars of value PMs bring to the organization: delivering outcomes (think - moving business KRs and goals), leadership (inspiring others), communication, helping others grow product craft and so on. I really love this framework. My recommendation is to first approach promotions and pay raise from a perspective of summarizing what types of value PMs in your org bring. It is not just in the "metrics", there may be other valueable things that advance the org/business that deserve getting people a raise. Then, I recommend looking at the market periodically to see the prevailing compensation for a given seniority role. Lastly, in the great resignation market, you want to be generous with your top talent contributors. Know who they are and make case for them as a manager - it will be much more expensive to hire someone new and grow them, if your top performers leave. 

I see a lot of PMs succeeding in startegy and operaitons roles. I have been tapped a few times for COO / Strategy & BizOps / Chief of Staff types roles because of the product background. Your ability to understand and connect the dots across business and customers, as well as manage stakeholders, is super valuable in all of those roles.

Being patient when I would like to be impatient. Product management is deeply humbling in that good things often take time. I like to say that I am "tactically impatient, strategically patient" - as in, obsess over small details and steps every day and treat them with urgency, but know that things take time to build, and big goals take time to achieve. But, being honest, this comes with a hidden frustration for me, an inherently impatient person :-)

First, like to work on problems that I am passionate about. I love to learn and make impact in areas that I think, pardon high brow speak, will make the world a better place. One such area of passion for me is helping people and teams achieve more through working together. I never even considered opportunities that I personally don't feel passionate about, as I know that would not make me happy at work. This is a privileged position to be in, and if you have to pick something in a different framework, don't feel bad please. It's okay to pick work that is just work. Second thing I consider is potential. Do I believe that a problem this product is solving has a high enough potential? Are there any macro signals suggesting that impact will grow? I love to understand the industries and their core current problems to make that impact assessment. Lastly, I look at the prospective manager. This is a person who will make or break your experience at a new company. Study them well, and make sure you have a great rapport.

There is a fork in the PM career path road: one is becoming a people manager, the other becoming an expert in a deep thinking product area sans managing a team. My recommendation is to figure out which one is right for you. Many folks want to jump into management simply because they think this is the only way to grow, make more $$$ and so on. That is not true. Big and small orgs I have been a part of value senior individual contributors that are passionate about their individual craft. Speak with folks from both paths, and see which one resonates more with you. Try mentoring people and see if you like helping others succeed through your guidance as a "management path" check. Then, share your thinking with your manager to get them to help you moving along this path. 

In short, you have to go from being a thinker to being a doer. The biggest mindset change is about learning when to stop with the analysis and transition into acting on things, in sometimes imperfect data coverage situation, and because of that imperfect coverage, how to experiment and iterate. Good news: it's doable, and I have seen folks succesfully making this transition. Good luck to you!