A Roadmap to Product Management for Students
By Andrew Vo
Who am I?
My name is Andrew Vo! Currently, I work in product management at Atlassian, where previously, I was a summer intern. Prior to product management, I worked across data science and software engineering at Shippit, Google and WiseTech. I'm also studying Computer Science at UNSW, where in 2018, I was the Co-President of the Computer Science and Engineering Society.
I'm really passionate about helping students (myself included) be more conscious about their career choices. I believe that if you consider carefully, the pursuit will be more meaningful and the destination more aligned to your nature.
If you have any more questions after reading, please don't hesitate to reach out! You'll find my contact details at the end.
Why am I writing this?
Lately I've been getting a lot of questions about Product Management. Sometimes when I meet someone for coffee, I find myself in deja vu, finding that I've already been asked the same question and given the same answer in another time. I want to capture these common questions so that I don't have to keep repeating myself, but more importantly, so people that don't personally know me can have their questions answered and have a platform with which to contact me directly with greater confidence.
Another reason is that I think there will be increasingly more people who would be interested in product management and more people who would be good at it (I'm speaking about Australia in particular). Β This is mainly because of an increase enrolments, hence in diversity in technology related degrees (there was 300~ students in my cohort at UNSW (enrolled in a degree in the School of Computer Science), this year there is 1000~). With a shift in diversity comes a shift in the status quo. Around me, I have found more students are consciously considering what they want to do in their work, what meaning it has and what impact it will make.
How does this have relevance to product management? It's not a path considered often, because it is easy to fall into striving towards what everyone else is striving towards. I'm not saying that doing what everyone is doing is bad, I'm saying that you should make sure you've thought about why you want to do it before you go down that route. So finally, for the people considering how to make the most of their work, I offer up product management as a viable option.
How to best use this guide!
I've written this for computer science students curious about what product management is, considering product management as a internship/graduate role or has decided they want to be a product manager and wants to know the best path forward. When I say computer science, I mean any degree where they teach you programming at a deep level (for 2-3 years.)
To allow for you to find what you want quickly I've written this in a FAQ format and grouped it according to what you might be interested in. However, I've organised it so that the questions and answers flow well together if you wish to read it from the start.
If you don't do/have done computer science, you can still find value in reading this, but there are sections where I talk directly to computer science students.
With that in mind, let's begin. I've compiled the questions I've commonly received with the most polished answers I can provide right now. Enjoy :)
β FAQ
π Considering the Role π
What is a Product Manager?
Product management is so fluid and variable between (and even within) companies that it is hard to really say what a product manager is. Let me try anyway.
From the book Inspired by Marty Cagan, a PM (product manager) is someone who "leads the product team to combine technology and design to solve real customer problems in a way that met[s] the needs of the business." However, the word "lead" here may give you the wrong idea due to the connotations of the word. A PM has no direct authority over her team members, instead she leads through influence.
A PM works in a product team, normally consisting of a designer, an engineering lead and engineers. Each component of the team (PM, design, engineering) drives forward different parts of the product development process. I use the word "drives" here intentionally, in that they're ultimately responsible for this part of the process but work collaboratively.
A PM generally drives the first few phases of product development as well as the general strategy of the team. That is, she defines what problems should be solved, considers when/how these problems should be solved (if at all) and removes roadblocks along the way to building a solution for it.
Defining Problems
To figure out what problems need to be solved, a PM doesn't just take her own ideas, stack rank them and choose the top one. This is a naive and frankly arrogant approach. She employs the skills and diversity of perspectives of her team members, using her own skills to bring out their great insights. She frames the problem in just the right way with qualitative and quantitative research which is presented to the team, and coalesces the insights drawn from them with her own and only then comes to a conclusion of what the problems are.
When/How
The "when" of solving a problem is generally driven by a PM but is priortised with the team. There are many considerations, and each function of the product team will naturally consider different things, such as: impact, effort required, how it synergises with other teams and the overall strategy of the company (more important in bigger companies) and how it fits in with the team strategy.
The "how" of solving a problem varies across teams, it can be a close partnership of PM and design, Β or driven by the designer, or it may be driven by engineers with a keen sense of the customer (sometimes referred to as product engineers.)
Roadblocks
A PM's work does not end when the solution is defined, there are many issues that may crop up along the way that requires a PM to provide input. How should users interact with the feature? We've invested 2 weeks into building this but it's going to take 2x longer to build than we planned, should we keep building it? The CEO has said we're moving in this direction, but what we're building doesn't align with it, what should we do?
These issues will crop up day by day and a PM learns quickly that she has to empower her team to answer some of the questions themselves, or she'll be constantly stuck in shipping mode. Slowly, her strategy for the future will begin to fade and she will become hyper-reactive.
Further Reading
Let me reiterate this point as it is important to keep in mind, the role varies between companies and seniority/across teams within companies. If you want to explore this question further, this post by textbook ventures interviewing a fellow product manager Jenny Chu is great, as well as Cracking the PM Interview (as a bonus, being good for interviews) and Inspired.
Is product management a good fit for me?
To answer this question for yourself, you should examine your past experiences and figure out what you've enjoyed the most. Specifically, I'd hone in on three things, in order of importance:
- What problems did you enjoy solving most? PM's solve user problems first which will solve business problems, whereas an engineer will solve technical problems first which will solve user problems. With this in mind, which problems did you enjoy the most? For your projects or work, did you find value in it because you enjoyed solving the technical problems and considering the user? Or, were the technical problems a means to an end for you? Did you enjoy thinking about the more external aspects of the project more (marketing, design, user value, value to business)? This is not to say that you can't enjoy the technical problems at all, rather that the other problems were of more interest.
- What did you like doing day to day? This is a consideration that many people forget or underweight in importance. In the end, it's the day-to-day work that will define your experience in the moments on the job. A PM suits those who like variety to their day, which can lead to frustrations around being productive (as most people need a solid block of time to get anything done).
- What are your strengths? Is what you're good at aligned with the skills best suited to a PM? Take a moment to reflect on what you think you're good at and read the question "What are companies looking for in a product manager?" However, because you're quite junior, I would not expect that you're skilled at all these things, which is why I've put this point last. I think as long as you identify with some of these strengths and you feel like you're naturally inclined towards some of the others, I'd consider it.
Just give it a try
For all the consideration you do, it's impossible to know for sure unless you give it a shot. If you're in the luxurious position of being in your penultimate year, apply to an internship. If you're looking for a graduate role, the commitment that is required to try it out is higher, so more consideration should be put in. Either way, give it some thought, it will help you in having greater conviction striving for it.
What are things I should consider when deciding on pursuing product management?
There are many great reasons to consider being a Product Manager, but before that you should consider if it's the right fit for you (question above).
In terms of the positive reasons you should consider it:
- Closeness to the customer/why: being focused more on the discovery phase of the work, product managers get to spend more time with customers as well as pondering the issues they face and how these issues can be solved through new features/products.
- Broader impact: the impact you're able to make is multiplied as you'll work with a team of engineers (as opposed to being constrained to what you can produce yourself.)
- Greater autonomy: this is not universal of the function, but generally there is greater capacity as a PM to work autonomously. Autonomy does not suit everyone though, if you prefer people to give you a clear idea of what needs to be done and to execute on this, then you will struggle.
Some "negative" things to consider:
- Distance from implementation: as a trade-off on working more broadly and directing the team, you don't get the satisfaction of having directly built something that works. For more details, read the question "What do I miss about being a software engineer/developer?"
- Uncertainty: the sorts of problems you deal with don't have definite answers. As a PM, the more you try to enact order onto the world, the more stressed you will become. The way this is generally approached is to get as good of an answer as is feasible with the given resources, and accept the uncertainty that remains.
- The boring parts: getting a team to move forward looks glamorous from the outside, but beneath the feature and product releases there is a lot of work, and a lot of it is not inherently interesting, things like:
- grouping and prioritising feedback, sometimes in the thousands.
- interviewing people of varying use-cases, seniority, maturity, team size, analysing what they said then grouping, prioritising it.
- convincing stakeholders that working on a feature is a good idea. This can take weeks or even months.
While the reasons above are applicable to being a PM, I think you can find other roles with similar perks. However, this is what I and others I've spoken to feel is unique to the PM role:
- More holistic view of the product process: as a PM you'll get to see a product from it's initial stages (what are the problems? who's our market), it's middle (designing and shipping) and it's end (did it solve the problem? what did we learn to do better next time?) as well as maintenance (improving and fixing features we already have.) You'll also get to consider things such as marketing/partnerships/customer research etc. in the success of your product. I don't think there is any other junior role that can provide such a holistic view.
- Ownership: the amount of ownership and responsibility in a junior role is truly rare. You'll feel challenged and have meaning in the work (if responsibility drives you) however this is a double edged sword. Your emotions become more closely linked to product, which will naturally experience ups and downs.
- Great timing: the industry in Australia is beginning to reach a point of maturity whereby it can support a greater number of graduate (i.e. new) PMs. More spots means more chances to get in. At the same time, there is a shortage of experienced PMs, with many companies needing to hire outside of Australia to find great PMs.
What made you want to become a Product Manager?
I wanted more closeness to the why and greater impact and autonomy. I also felt that the PM role aligned much more closely with the skills I'd developed at university, specifically with people, with leadership and with navigating uncertainty.
What are the future opportunities for a Product Manager?
- Group Product Manager/Head of Product/VP/CEO β this is the progression path for PM's on the management track.
- Principal Product Manager (basically a really good + hopefully high paid PM.) β if you'd rather not manage people, you can still progress, though opportunities are more limited as not all companies have progression beyond a certain point for people who don't manage.
- Start your own startup β being a PM gives you a more holistic view of the product process which aligns closely with the skills required of a startup. A lot of startups/companies are founded or run by a former PM.
- Go back to engineering β you can always go back if you don't enjoy it.
- Design
- Fuck corporate life, go live in the forest.
π The Path / Interviewing π
What are companies looking for in a Product Manager?
This only applies to interns and graduates. From what I have seen, tech companies pattern-match on a few experiences:
- Leadership: making tangible impact as a leader, typically societies.
- Technical/problem solving experience: could be anything that demonstrates experience solving complex problems, i.e. software engineering work experience, consulting etc.
- Start up experience: being in or running a start up.
- Personal projects: blogs or apps released to users.
- Experiences across the product cycle: business, design etc.
These experiences map to underlying traits/abilities that they are looking for: communication, leadership, product sense/passion, analytical/problem solving ability, entrepreneurship mindset, passion for the user, design sense.
You don't have to have all of the above experiences, however it's expected that you've experienced most at a reasonable level or some at depth. It isn't a good sign to a recruiter (or to be honest, if you're fit for being a product manager) if you haven't gone out of your way to pursue things. Being a PM is a demanding role which is amplified when you're an intern or a graduate, because of your lack of experience. You will compensate with tenacity, passion and curiosity.
I hope I haven't scared you off! I don't want you to think that you need to be amazing at everything to be a PM. PM's have strengths in different areas, there are design-focused PM's, business-focused PM's, technically-focused PM's. There is a enough flexibility to find a way of working and a team that suits your strengths.
What unites all these different PM's is a passion for solving user problems and translating them into business value.
What should I do if I want to become a Product Manager?
The short answer is to do the above patterns.
For the long answer, first I'd consider why you want to do it. You'll find that the why behind what you want will translate well into the steps you need to take next. For instance, what I craved most was more closeness to the why and greater impact and autonomy, so I pursued a role in a startup where I had greater autonomy (which led to more impact) and I led CSESoc as Co-President which was a role I thought I could make great impact in. Unwittingly, these things where the key to getting a PM role.
Once you consider why you want to be a PM, I would do things that align with what you like and overlap with the patterns above. However, let me warn you. I'm an advocate for consciously creating your future, but the downside is that you begin to do things because of the things that they might lead to, compromising the value and joy of the activity itself. If you can, think about what you should do, forget that they might lead to product management and just pursue it because of the joy you find in the activity.
What are product management interviews like?
This varies heavily from company to company, let me go over common interview styles/tasks:
Product task: analyse a specific or chosen product. What's good about it, what's bad, what would you improve and how? This is typically given as a screen before interviews.
Behavioural: typical STAR type questions, what is your greatest failure? Tell me about a time when you had a deadline, etc. . For students with a Commerce background, these shouldn't be too tricky, but for Computer Science students, I'd practice these carefully.
Technical: product type questions, they range from generic (tell me about a product you like, what would you change about it etc.) to more specific (tell me about the marketing of a product you like, why? what users were they targeting?) and more abstract (how would you design an alarm clock for the blind?)
Read the next question to learn about how to prepare for them!
How should I prepare for the interviews?
This section in particular I wish I had much more time to flesh out. While these points are related well to PM and preparing for Atlassain, they are brief and high level. I really suggest reading further here and to reach out for more specific help for interviews. (Tips for further reading at end of question.)
This is a hard question because the interview processes for PM's are so varied. I'll start with some general tips and then ones that relate specifically to Atlassian but may be applicable elsewhere.
General Tips
When you're preparing for anything you want to practice the specific cognitive tasks that you will be performing in interviews. For product management interviews this would be critiquing products, thinking in a structured manner, coming up with product ideas, thinking around metrics/analytics and having thoughtful reflection on past experiences. The best practice, when feasible, would be to answers questions as you would in the interview. When practicing, try find someone knowledgeable to critique openly what you could improve on for your answers, rinse and repeat.
This isn't always practical though, when helping people with interviews I've found that some people have no idea how to effectively answer some of the questions that might be posed in an interview. This is especially true of students with computer science backgrounds. This is not because of some deficiency in natural ability applicable to you, it's merely a lack of exposure. So, if you find your self particularly lost I suggest two things, look up a structure or framework which you can use for the question as well as sample answers and/or have someone who's experienced describe and answer questions to use as a guide.
I would also spend a bit of time reading up on what product management is and reflecting on why you might be suited for it and what you could bring to the table. Learning about the products of the company you'll be applying for helps too!
Structured Talking
When I initially begun practising I ran into a problem, basically I knew what I wanted to say, but when I got down to saying it, I would meander off into some random tangent. It boils down to thinking about what your key points are before you say it, giving the problem and why it matters before diving into the solution. However it's important not to let structure override the flavour of your answer (lest you be seen as a robot who has pre-practised their answers) but its immensely helpful so that you're able to say everything you want to say in a manner that makes you seem like you know what you're doing ;).
Reflection
Reflecting on your past experiences thoughtfully will allow you to demonstrate an awareness of cause and effect, that you think carefully about what you do and how you do it and that you're open to learning from your experiences and feedback. Because introspection is a natural habit for me, I didn't have to work on this much, but if it isn't something you routinely do, I would sit down for awhile and reflect on past experiences you've had that might be aligned to product management. Specifically, what happened? How did you approach it (what were the steps of your approach)? How did it turn out? What did you learn?
Further Reading
For more information and tips on what to expect and for preparation I suggest Cracking the PM Interview and The Product Manager Interview. Here's a site that generates interview questions too. If you're in the process of interviewing, I highly suggest you seek out more resources that are specific to the interview you're doing. Also, feel free to contact me (details at the end) for questions on specific interviews.
π More Specific Questions π
What kind of work might I do in a product management internship?
In an internship, you'll generally be supporting a PM in order to learn the ropes. You'll get less ownership but as a result more breathing room. But don't mistake less ownership for less exciting.
During my internship, I worked on a strategy piece (which we pitched to Scott, the co-CEO) which forms a key part of the Jira Software strategy moving forward. Another PM intern took charge of improving the function of dates within Atlassian products. She led the project from conception to it being built. Another intern ran the Early Access Program for Jira Premium. He interviewed 20+ customers, teased apart what they liked and didn't like about the current product offering and worked with engineering to build new features from the insights he derived from the interviews.
You'll find that the projects given will be incredibly diverse, but it you engage wholeheartedly, you'll gain plenty from the experience.
What kind of work might I do as an Associate Product Manager (graduate)?
If you start as an APM without prior experience, you're likely to be put on a team with another PM who you can learn off. Some things that APM's have worked on:
- PM'd the team that shipped a new navigation system for Jira & Confluence.
- PM'd the team that executed the biggest monetisation model changes to Trello to date.
- PM'd the team in charge of the new Jira onboarding flow to increase evaluations and reduce churn.
Can I be a PM if I have a technical degree?
It's ironic that I get asked this question from students in computer science because much more often the inverse (Can I be a PM if I'm not technical?) is asked.
The answer is, definitely. In fact, a lot of PM roles require that you're technical.
What do I miss about being a software engineer/developer?
When I was a developer, I enjoyed my work more because of the output than the work itself. That being said, I really do miss the quick feedback loops. You can run a piece of code, see if it builds, see if it pasts your tests, see if the output it produces makes sense. I always got a little rush when I wrote something that worked.
Unfortunately, you can't build people, you can't run tests on your strategies and you can't see the output of your features until a long way through the process. Being a Product Manager is operating constantly in a "I'm fairly sure this is right, but honestly, I have no fucking clue" mode. If you can get the expected outcome you want 50% of the time, then you're damn good.
It is more stressful because of the uncertainty, but it does teach you how to deal with these similar constraints in life.
How has computer science helped/hindered me?
Computer science has helped significantly with having the right ways of thinking when approaching a problem. For example, it might seem odd but abstraction is such a great thing to know when working on problems with others. You need to make sure you're approaching the problem from the right level of abstraction to begin with and you need to make sure you're both thinking at the same level, it was surprising how often people view the problem the same way but disagree because they're operating at different levels.
A benefit that is also sometimes a hindrance is being able to converse with engineers about the technical details. I think engineers respect you when you know what you're talking about and it's easier for you to understand the technical constraints so you can translate them to design/business ones. However its easy to overstep your boundaries and think too much about the implementation, compromising on the autonomy of the engineering team.
Finally, computer science narrows the way you see the world. This isn't unique to computer science in particular though, when you get deep into anything you start seeing that every problem you encounter can be solved with this knowledge. There are definitely things you can do to counteract this, but I'm still learning.
"If all you have is a hammer, everything is a nail."
Overall, it's helped more than hindered. All the negative aspects can be counteracted by being cognizant of them.
Final words / Contact
Having written this and spent time redrafting and getting feedback, I realise that there's always more to be done. I wish I had all the time in the world to go into more detail and expand on each point, but unfortunately I, and the scope of this piece, has it's limitations. I will revisit this and rework it as I get deeper into the field and have gained more expertise.
Let me end by saying, I believe that as long as you consider carefully what you want to do in terms of how it aligns with your vision of the future and your nature, you're bound to find success, by your evolving definition. I hope this has helped you even a little on your journey!
If you have any further questions, want advice for specific interviews you're facing or want a referral to Atlassian, please don't hesitate to reach out at: andrew.vo997@gmail.com.
Check out the original article here: https://www.notion.so/A-Roadmap-to-Product-Management-for-Students-e5c9c2b7ced440fd9392c05ae08da12d