TMI: The product management interviewing guide no one asked for
*Salary information up-to-date as of Feb 2022
Atlassian provides the following definition for product management:
Product management is an organizational function that guides every step of a product’s lifecycle — from development to positioning and pricing — by focusing on the product and its customers first and foremost.
Among some circles, product management has replaced what consulting or investment banking was 10 years ago — it’s a hot and lucrative industry (long-term salary prospects for product managers can easily get into multiple hundred thousands), and is multidisciplinary enough that it attracts everyone from CS new grads to bootcamp attendees to career switchers.
It is a field that is rife with hype, yet seemingly difficult to get into. The prevailing advice for product is mixed, to say the least. Do you need to learn to code, or don’t you? Do you need to know Python? Do you need experience as a designer or software engineer beforehand? Do you need to launch your own product first?
I’m not qualified for product.
I came into product with no programming experience, no serious technical expertise, and no ‘launches’ under my belt. My recruiting experience into product took 3 months, but if you factor in all the hmm-ing and haah-ing I did, it really took several years. I was plagued by the belief that I was not qualified or capable enough for the role.
If you’re reading this, my assumption is that you, like me, have an interest in product, but are doubtful about your ability to get into it. You may feel that you’re lacking in technical expertise, or that some sort of stepping stone role, à la business analyst, product support, or functional consulting, is necessary before you can even consider applying.
I’ve now started my new job and have had the opportunity to reflect deeply on the experience, including everything I learned. In summary, I applied to over 100 companies, interviewed at 19, and was given 2 offers. Throughout, I collected data both on the types and lengths of interviews conducted, my overall success rate through each, and salary information. My intention with this post is to provide transparency, and aid others to get into this field. I also want to talk about my experience overcoming the famed ‘technical’ gap.
The ‘technical’ gap refers to the notion that a product manager cannot be successful without a technical background, typically either meaning direct experience in a software engineering role, hands-on experience launching a software product of their own, or expertise in a programming language.
In my opinion, this notion is both harmful and patently false, and serves only to exclude newscomers from the role. Many disenfranchised populations either lack the time or the resources to learn complex and evolving technologies. This notion also overtly downplays the overwhelming importance of soft skills in product, many of which are learned directly through business roles. As technology companies scale, the necessity for smart product managers — and smart employees in general — will expand. We need more applicants, not less.
This piece will cover 3 broad sections.
- The “What” of the Interviews: interview format and length, overcoming the ‘technical’ gap, what to expect in each round
- Salary transparency: remote vs. in-person, Canada vs. US, negotiations
- Specific advice to non-technical applicants
Interviews: What to Expect
Let’s start with some stats.
I estimate 100+, because I legitimately do not know how many companies I applied to. At my peak, I was applying to well over 15 companies per day. I was using a combination of AngelList, LinkedIn, Indeed, and friend referrals. No one likes to be the spam applicant, but — it works!
A glance back on my Google Calendar indicates well over 20 hours/month dedicated to scheduled interviews. That doesn’t count interview prep (watching videos, reading guides), completing homework assignments, or one-off recruiter calls. This is not to discourage anyone away from recruiting for product, but rather to recommend applying for product only when you have the time to dedicate to it. Be prepared to fully go in.
I deliberately exclude the infamous ‘product sense’ or ‘product execution’ interviews, since there’s a plethora of better literature available here, here, and here. For my purposes, I’ll shed some light on other, less frequently talked about interviews.
a) Homework assignment
What is it: PPT, Prototype, or ranked list of features where you comment on a roadmap or upcoming feature set
What’s being evaluated: Prioritization, basic user story estimation, creativity
Watch out for: Be careful on how critical you are. Your interviewer may have built the very roadmap you’re commenting on!
Sample questions:
What are two ways you could execute on Feature A?
The design manager recommends a UX overhaul, but the engineering manager actively discourages this. How will you prioritize?
Our competition is building Feature B. Should we do the same thing?
b) Technical
What is it: Dataset or estimation question. May include: SOP (size of prize), user base, estimated revenue or revenue loss, opportunity cost of a feature
What’s being evaluated: Basic quantitative skills, familiarity with statistical concepts, finding actionable insights in data
Watch out for: Resist the urge to sound knowledgeable when you’re clueless. Ask questions!
Sample questions:
What do you think is the average income of this slice of users?
We’ve experienced a 35% drop in revenue. How much of this can be attributed to Feature A, which we launched six months ago?
Who are our highest value customers, based on this dataset?
c) Design
What is it: Design thinking, personas, discovery, prototyping, or wireframing work. Will almost certainly involve a whiteboard tool (Miro, MURAL) and/or a design tool (Sketch, Figma)
What’s being evaluated: User empathy, understanding of accessibility and HCD concepts
Watch out for: Go into design interviews with an open mind, focusing on functional over perfect. Have backup plans if someone vetoes your idea.
Sample questions:
This CTA has a lower CTR than others, even with the same visual treatment — how would you improve it?
A new client we onboarded is raising a lot of redundant tickets related to Dashboard. How can we address this?
d) Engineering ‘gut check’
What is it: Behavioural with an engineering lead or manager. I can’t stress how important this round is, because the number one thing non-technical candidates, (but especially consultants) will have to overcome is how they will earn the trust of developers. You need to prove without a doubt that you are not what so many people picture consultants to be — all talk and no walk. More on this in the last section.
What’s being evaluated: Interactions with technical teams, how quickly you can understand technical concepts. These concepts of leverage and decision-making were introduced to me when I read Brandon Chu’s blog several years ago, and I highly recommend them as initial reading.
Sample questions:
How should developers view you on the team? How involved are you with them on a daily basis?
The last two releases have had more bugs than usual. What’s your first action?
The engineering lead and CEO are disagreeing on which feature to implement next. How will you mediate between them?
Salary and Compensation
Disclaimer: I am a young woman of colour — it’s proven that people of my demographic are less likely to negotiate, and in turn are less likely to receive generous offers. I negotiated every offer I received. Remember to always negotiate!
Disclaimer #2: Some companies, which have fully adopted remote work, pay their best salary regardless of where you live. Others will benchmark depending on where you choose to work from, and adjust accordingly if you relocate. US salaries also presume high healthcare and insurance costs, which are a lesser factor in Canada.
Of the 19 companies I interviewed with, I was able to get salary ranges for 11 of them. They are, more or less, equally split across the US and Canada. These estimates apply to roles with titles of “Product Manager” and “Associate Product Manager”, the latter of which is more entry-level.
The numbers I used presume the bottom of provided ranges, since the majority of readers will be new product managers receiving more entry-level appropriate salaries.
My main observation while recruiting was that Canadian companies lag significantly behind in terms of compensation. This was an unfortunate reality that I only slowly realized — most Canadian companies I interviewed with were offering salaries, even for experienced PMs, that were below or at my current compensation. This was true regardless of the company’s stage (seed to Series C and beyond). This is problematic, particularly in the GTA, as the latest data suggests that to afford a representative home in Toronto, you need to make over 200k — 83k isn’t half that.
Another observation among Canadian companies was a stronger push to start in an APM position, then gradually work my way into PM. This was in contrast to US companies, many of whom were open to me immediately starting at a PM level.
While APM responsibilities are similar, pay is almost always lower and there is usually a 1–2 year period before you will hit PM. Starting in an APM position can be helpful if you lack confidence in your abilities. It can also be a way to artificially deflate your salary and work experience, so tread carefully.
The highest Canadian salary quote I received was equivalent to the lowest US salary quote. Based on my recruiting experience, I’ve found that product management is more lucrative outside of Canada. This is unfortunate, as many of the US companies I interviewed with have hybrid or return-to-office work as a contingency on the offer, meaning relocation is a virtual guarantee when COVID ends. I like where I live, which made my eventual decision more difficult.
There are a number of memorable interactions on salary negotiation specifically with Canadian companies. In one instance, I shared my desired salary range (never do this) in the first round of interviews. My number was out of the target for the company. Instead of stating that my target was out of range, the interviewer argued with me that I ‘should’ve anticipated a pay drop, coming from consulting’ and that ‘I should look forward to the long-term prospects of product management’. It’s meaningless to argue because the numbers speak for themselves. You can choose to get paid more now, or you can choose to get paid more later.
Another major part of compensation involves stocks or stock options. I exclude any discussion of them here because I only received two offers, meaning I can’t comment on what those TC packages would’ve looked like. Keep in mind that stock options are speculative and become less valuable the earlier the company is in its funding rounds (or more valuable, depending on who you ask). There is also, of course, the question on benefits, vacation, WLB, company-funded training, all of which you may value differently. I leave it to readers to make personal judgements on how these matter to them.
The tl;dr:
For Toronto applicants, I would encourage you to seek jobs outside of the GTA that offer remote work. With inflation and — literally — skyrocketing cost of living in the city, stagnant wages in Toronto tech are simply no longer worthwhile. There are exceptions to this, mostly with larger and more established tech companies. You may also connect deeply with the company mission, or predict an imminent IPO. Value is subjective!
Tips for non-technical applicants
I believed, falsely, for a long time that product management was a space that deserved to be gatekept from others. When I held coffee chats with PMs or senior product leaders, I was often told that becoming a PM was unrealistic for me, with no CS background, and without having deployed an app of my own. Learning to code was mandatory. I needed to go back and earn a new degree because I had the wrong education for it, even though it’s one of the most academically diverse industries.
A number of years ago, while I was intern on the comms team at Shopify, I was speaking with a software engineer who was one of the few women on her team. She’d overcome barriers herself, and was sympathetic to my struggle trying to get into product.
I just don’t think I’ll get in.
Why?
I can’t code. I don’t have an app. I never studied CS.
But most of product is just having conversations, and understanding things, and making decisions, and knowing how to fit things together. Why couldn’t that be you too?
This isn’t to say that that you can become a PM by virtue of having an open mind and being a good conversationalist, but rather to emphasize that great PMs are the ones with the ability to make good decisions with limited information. Underlying this are traits like curiosity, humility, and communication skills, none of which are exclusive to a technical background. Technicality is an enhancement to product management, not a requirement.
I want to emphasize this point. Tech is a privileged space that offers high-paying roles which historically have been inaccessible to many groups, including those from non-traditional academic backgrounds, lower socioeconomic strati, and women and queer folks. The more we prop up barriers to entry, the less smart applicants we get. The aim of the product discipline should be to attract the maximum number of intelligent and curious people possible, not to discourage them from even starting.
Overcoming this gap is easier now than it was 5 years ago, because of how much the field has grown, and the sheer number of resources dedicated to acing product interviews. I’m writing this blog not to tell you how to enter product, but to tell you why — because you can!
My tips for non-technical applicants are short and sweet:
- Be creative and ‘big picture’ thinking. All this to say to not stress on details you don’t know. If you come into the interview not knowing how to code, you won’t learn it in 15 minutes. Do your best and focus on solving what you can.
- Learn to ask questions. And especially dumb questions — what is this? Why are we doing this? Who is this for?
- Focus on your specialties outside of coding. What are you offering the team that no one else has? For me, this centered on UX experience and first-hand experience working with large offshore teams.
- Cut out business jargon. (An adjustment for me personally, coming from consulting 🙂)
- Be the kind of person people want to work with. Amiability and humility go a long way.
I’ll be continuing to write about tech, and in particular my lessons on product, as I start my new role. While I will miss and am grateful for what my previous role offered me, I’m looking forward to all the new ways to grow and develop. I hope other job-seekers looking to make this same switch as me find these tips helpful, and find the jump a little less jarring as a result. Good luck!
