Disclaimer: the following piece reflects my own views and opinions, and no content should not be taken to represent the perspective of Atlassian (or other employees at Atlassian, unless explicitly stated).
“Hang on, so what exactly do Associate Product Managers do?”
Despite having previously researched the role and talked to APMs, that’s the question I was still asking when I first started as one of eight bright-eyed, bushy-tailed APMs in Atlassian’s APM graduate program in Australia in January 2021.
As a Computer Science/Marketing student, I was excited by the opportunity to tackle problems holistically through the intersecting lenses of technical feasibility, business viability and user desirability. Beyond that, being an APM seemed like a chance to own a problem-space long-term to go through the wins and losses of building, measuring and iterating.
Atlassian's program stood out as the best training ground for junior PMs in the Australian market, and despite getting rejected when I first applied to be an intern, I knew I had to give it another crack.
But when I stumbled into product management, I had only a vague ‘map’ of what the role looked like in my head.
The actual 'territory' of how to thrive as an APM didn't quite look like my map, and boy, did I learn a thing or two along the way.
9 months in, here are the 9 hardest lessons I’ve learned as an Atlassian APM.
If you’re a current or aspiring APM, hopefully by the end of this blog, you’ll have a much better understanding of how to set yourself up for success in a global tech company than I did on Day 1.
Let’s dive in...
Get dumb is a strange phrase for a role where you sometimes get to work on product strategy.
But in order to be in a position where you can make significant product decisions, you need to understand the basics of your product, your customer, your market and your company’s broader portfolio.
Starting off, I dived deep into our internal rabbit hole of Confluence pages, and there was a ton of great info to get up to speed.
At the same time, information can change very quickly, it’s hard to know which information is relevant, and even relevant information may be hard to understand without other context.
So, in hindsight, the cliched-for-a-good-reason advice that helped the most was asking questions.
Dumb questions. A lot of them.
It is your responsibility to drive your focus area to success, and you need to know your stuff. Don’t make assumptions. One of my mistakes was not asking dumber questions earlier!
The word ‘associate’ might be in the title. But this is far from your typical graduate role.
Even though I had friends who had done the APM program at Atlassian, I kinda still thought there’d be a fairly long period where I’d be shadowing & supporting the more senior PM on my team, helping do competitor research, design customer interviews, write requirements, yadayada.
Different tasks that needed to be done.
But the biggest paradigm shift was pretty quickly, there was nobody giving me specific ‘tasks’; my manager placed trust in me to own my time.
You’ll have a manager, buddy, and mentor to spar with and get feedback from, but ultimately, you decide how to spend your time in the most effective way possible.
Real talk, the first six months were a pretty intense firehose of learning and not always smooth sailing!
I’m now owning a team independently, leading cross-team projects, and driving our future roadmap, OKRs & vision, but to get to the point where I felt even somewhat comfortable doing that took me a long time.
The lens I’ve come to: PMs are gap-fillers. Keep a pulse on the fundamental engine of your team and look for opportunities to reduce blockers, create clarity, foster collaboration, resolve disagreement, and make things easier for the people around you.
Coming into such a nebulous role, without a clear set of tasks or clear functional understand of “Ah, the PM does X, Y, Z”, my ‘anxious overachiever’ inclination was to obsess over finding the right way to do allto all these murky new PM things.
What’s the best practice for product requirements, prioritisation, problem discovery, success metrics, cross-team collaboration, meetings?
I have encountered such a diversity of approaches to PM at Atlassian that I think here, the best thing to do is:
Every product and team has different needs, and as such, product management is not a one-size-fits-all discipline.
A piece of advice I received from my buddy in the APM program (a Senior Product Manager) is to remember the fact that I bring something new to the company (especially having come from a startup environment).
Starting off, I was scared of doing the wrong thing and tried my best to rigorously follow the templates and fit into the box of what Atlassian APMs are supposed to do.
But in more recent months, I’ve built the confidence to realise there are a lot of things at Atlassian that I genuinely think there are better ways to do.
Drawing upon my experience in sales, marketing and running a startup on the side has changed the way I approach communicating internally, engaging with customers, and iteratively testing new processes internally.
💡 Got a PM interview? Our PM interview drills help get you in top form
In ultimately being responsible for ensuring my team delivers on the vision and OKRs (Objectives & Key Results) for my product area, at times I felt a pressure to be across and drive every decision and data point going into the product.
But beware the lone wolf superhero approach. PMs are absolutely NOT the expert on everything.
You get to work with some amazing engineers, designers, marketers, content designers, architects and salespeople.
They will all be much better than you at certain things, so it’s key to build a sense for when there’s a better person for the task or decision at hand.
PMs might own the ‘what and why’ of the problem being solved, but don’t be afraid to go multiplayer here.
I’m a firm believer that great ideas can come from anywhere across the business, so proactively ask your team about their understanding of the area and any hypotheses they have.
The PM’s job is to leverage the superpowers of those around them. Do this and you’ll come to much better choices.
It’s terrifying being a fresh university grad and being asked by much more senior people on what the best thing to do is for the customers and the business.
You’re kinda somewhat thrown in and expected to have an opinion within a matter of weeks. Now, as you’re ramping up in the first 6 months, there will be a ton of stuff you don’t know, but even then, things are going to be far more productive when you come to meetings and discussions with a strong opinion, provided you acknowledge the things you don’t know.
When you give people an open buffet of options about what decision to take without clear recommendations (as I’ve made the mistake of doing), you either get crickets and nobody drives a decision, or open up a never-ending series of ‘2 cents’ suggestions that lead you nowhere.
I’ve seen senior leaders at the company give me very different recommendations, because everyone brings different context and experiences to the table; at the end of the day, it’s unlikely anyone already has the complete picture in their head.
Your job as a PM is to go deeper than anyone else and formulate the best informed opinion on your specific area of ownership.
Now to do so, and this sounds intimidating, but putting out some early initial opinion gets the ball rolling and helps guide your team on the right questions to ask.
As new information surfaces, your opinion might be wrong and that’s pretty normal.
Changing your mind is a sign of strength, not weakness, as long as you call out why this information makes a significant difference.
Great PMs are not right 100% of the team, but they do update their mental model based on fresh data.
One of my weaknesses coming into the APM role was the habit of over-analysing to the point of analysis paralysis.
Don’t get me wrong, product managers absolutely need to be able to switch modes between conceptual thinking and getting in the deep details of writing requirements and interpreting customer data.
But inevitably, you cannot guarantee the ‘best possible decision’.
The more time you spend trying to spar things with more teams, or collect more data, or talk to more customers, the more work you might be creating for engineers and designers that doesn’t need to be done in the first place (and believe me, I’ve f*cked up here).
At a certain level of info (40-70% of what you would need to make the best decision), you should progress forward and record what your unknowns are.
Most decisions are two-way doors, and putting a first iteration in front of customers is likely a much better way to get a sense of the right decision than debating a feature internally for weeks on end.
As a PM, you’ll have to zoom in and drill deep on the details of customer cohorting, feature flags, release track, different user types & licences, and a jungle of edge cases.
Confluence documents might be a great way to keep track of all this information, but those same documents are not always the best communication tool.
I’ve shared internal updates in the past where teams have gotten lost in the technicalities and I failed to capture the real ‘so what’.
The key learning here, especially with wider audiences, is keeping things to the high-level TL;DR and what this means for our customers, with a pathway for those in-the-know to dig deeper.
Consider a synthesised Slack message in a big group chat with the finer details kept in the thread, or a ‘Goal / Outcome’ panel at the top of pages to keep the ‘why’ top of mind.
In a world with too many pages and messages, even Loom videos can be a great way to synthesise the most important parts of the story.
A classic trope in the PM world seems to be every PM espousing the wisdom of “talk to customers” and then all of us barely finding the time to actually do this.
But there’s a secret hack many PMs don’t take advantage of to rapidly accelerate their customer understanding.
Talk to the employees who talk to customers most: pre-sales, solutions engineering, customer success, support, and the like.
These folks are aggregators of many, many customer conversations, and have a great pulse on the key things customers are excited about, frustrated with, confused about or perhaps don’t even know about in regards to the product!
Set up time regularly with them, include them in early problem discovery when building new features, and work with them to get the story out to customers about new features + pull in feedback.
One of the blessings of starting your product management career in an APM program is being able to co-learn alongside friggin’ smart, ambitious and genuinely kind people: the other APMs!
Everyone brings different strengths and stories to the table, and in my opinion, one of the biggest selling points of the program is the chance to spar with one another, learn from one another, and sometimes just have a rant about the steep climb of being an APM.
If you have specific questions about Atlassian, the APM program, or product management more generally where you haven’t been able to find answers elsewhere, shoot me a message on LinkedIn or Twitter.
Real interview questions. Sample answers from PM leaders at Google, Amazon and Facebook. Plus study sheets on key concepts.