AMA: Atlassian Head of Product, Enterprise Strategy & Planning, Natalia Baryshnikova on Building a Product Management Team

It's easy for teams to over-index on day to day customer issues and lose sight of innovation; the opposite is unlikely. If your team has customer focus figured out (if not, tackle that first), there are three things that have worked well for my teams to keep the balance: * Every member of the team (especially junior!) understands and can speak to the big picture product strategy and market * Intentional and structured approach to include customers into discovery (vs letting them always drive the agenda when speaking with them) * Incentives to innovate Why does this matter? * Big picture thinking: before you can ask the team to "innovate", you need them to fully understand the playing field - where does your product play, why do you win, who is it for etc. Too often junior team members don't even fully comprehend what the product does or what is the strategy overall, and leader do not invest time into educating the team repeatedly. As a result, the team won't have the right information to even have "aha moments" and spot the new opportunities that lead to innovation. Bonus points if you not only communicate strategy to your team repeatedly, but also empower more junior team members to present said strategy to customers - this will increase their comprehension and comfort with it, thus empowering them to explore its gaps/boundaries and innovate. * You don't have to always listen to customers: In fact, most customers appreciate listening to you, and providing feedback on your future/ideas, rather than telling you what's working or not working now. However, it is easy to fall into the habit of letting customers fully drive the agenda of the meetings between them and the PM team, always making a "listening session" or complaints about bugs, feature requests etc. An easy way to break this cycle is to create programs around discovery, new capability testing, design feedback sessions and the like - customers will be happy to participate in those structured sessions, especially if you have already established their trust that and practiced listening to them. Lots of ideas to explore and innovate on will come from those sessions. * Incentives: As a team leader, you'd have to have a clear definition of what do you see as innovation (is it novel ideas for building new capabilities? Suggestions on how to expand into new use cases? Experimentation? Something else?), and once you share that with the team, you need to track and celebrate behaviors and outcomes that are associated with your definition of innovation. A lot of innovation programs, especially in big tech, do not pick up because teams see no good reason to spend time on those vs something else. And, since innovation often has a risk of not working out, it's important to incentivize not just outcomes, but also behaviors - e.g. "we tried 5 ways to improve X and none of them worked" deserves recognition and not being frowned upon.

At Atlassian - and I know this is true for other product organization with a strong writing culture - we invest a lot into internal comms about PM updates and activities. My general recommendation is a ratio of 80/20 for sharing updates async (think in writing or recorded form) vs sync (think enablement calls for your sales/customer success teams). My favorite examples of async updates that keep the team informed, and their frequency that has worked best for my teams: * Weekly Loom updates (or any video updates) covering "what's new this week" - share this broadly with anyone who's interested * Per-project weekly updates - we use Atlassian projects at Atlassian, but it can be any tool of your choice that sends followers/watchers a notification about a specific project update, usually weekly * Long-form blog posts and product strategy pages share-out - very important to refresh the broader company's memory on why are we here and what's our end game - do not assume people will remember this, and keep their memory fresh with updates every 1-2 quarters. For sync update communications, I recommend mapping your internal teams that are planned recipients of these comms, and ask for their opinion of what frequency/format would work best for them to help them do their job. I would pay special attention to asks from sales, customer success and marketing teams, as they are your allies in getting your product (or its monetization capabilities, for consumer tech and sales) into the hands of customers.

First, let's define what "well-rounded" means. Commonly, there are a few types of parameters that go into this: * Seniority balance - you don't want the team to be all too senior or too junior * Skillset type - this often implies having a diverse team with a variety of backgrounds and life experiences that shape their skills * Newbie/oldie ratio - often overlooked, but I believe teams perform best when they have a steady, but not overwhelming influx of new voices I would argue that the definition of what represents a well-rounded team is very different depending on: * Size of the team * Maturity of the product team is working on (Is it zero to one? Post product-market fit?) Here's how this plays out in different scenarios: * If your team is small and product is new (or pre-launch), it is best to not worry about seniority balance and newbie/oldie ratio, but solely focus on the skillset types, and ensure team has enough variety of voices to build something comprehensive, but not to a point where the variability requires constant re-alignment among PMs. * If the team is large, and the product is new, your problem is likely too many people and the team is impossible to become well-rounded. Don't overhire and set up your team for failure. * For small teams on mature products, the newbie/oldie ratio matters a lot because newbies generally have an easier time to try out ideas that may not have worked out in the past, but can succeed this time. * Lastly, large teams on mature products need their leaders to pay attention to all three types of "well-rounded team" parameters.

There is nothing inherently wrong with having someone with a title "product manager" reside on a CX team. The caveat is depending on what the expected scope of that PM is, they may not be set up for success, or they even may be playing a role that (unintentionally) puts customers at a disadvantage. Situations when it's good to have PMs be a part of CX org: * They help build internal tooling for CX or integrate company's own product and CX internal tooling in ways that helps teams better understand customers and ultimately, serve them better * The product offering of the company is in the CX market, and that PM team is a "skunkworks" unit driving experimentation and dogfooding of the company's product leveraging own CX team as customers * These PMs act as outbound PMs focusing on collecting, summarizing and distilling customer needs into specifics requests for other product teams, thus saving time and effort on research and holistic discovery around new capabilities Situations when it's NOT good to have PMs be a part of CX org: * It's a move to get the overall PM org "closer to customers" instead of finding a way to incorporate customer centricity into all PM practices and rituals * Overall "nesting" of PM org within CX - this will most likely rebalance incentives on customer renewals and focus roadmap on addressing (often tactical) customer asks, depriving the organization from an ability to build and execute on a bolder product strategy, leading to business disruption and ultimately, loss of innovation/customers

The hardest part in this scenario is to accurately capture the moment when you tap out of your own capacity and need to bring on someone else. One potential framework for this: keep a list of things (as in, capabilities to explore/build) you would want to start today if you had bandwidth; the moment this list has five items on it is the time to hire another PM. Make sure you're honest with yourself and only list things that you 100% believe in and that are truly major, not small improvements. Then, repeat this process for every net new five items on the list until you hire 3 PMs under you. When you are looking for those early PMs, take note of their ability to scale as team leads during the interview process. Do not hire someone brilliant if you think they would not scale to lead a team within 12 months. This generally implies you want to opt for somewhat senior PMs; however, keep your eyes open for folks that are hungry and capable and can hyper-scale quickly.