To be honest I didn’t want to write on product management. Mostly because practically everyone writes about it since so many people want to make a transition, and also because during this economic downturn (which I very closely track, but that’s maybe in another post) most people are concerned with having any job, let alone making a switch. I didn’t plan to write even though it’s been my primary career goal for at least 3-4 years and I’ve been almost exclusively focused on it for the past year, which also explains my absence in writing in general. But…
Today marks about a year since I’ve become a Product Manager. And I actually think now could be a great time for making career changes, as opportunity windows become open during the chaos. Some of the biggest gains can be made in the times of recession and panic, if you keep your cool and be strategic. I won’t go into explaining what a PM does, since there’s plenty of resources that dwell exactly on that. Instead I’m going to write what I’ve learned in the past year and what helped me make the transition.
I’ve been lucky enough to get into a PM role, and moreover at a global FinTech company, which is an unreal combo I couldn’t even fantasize about a few years ago. PMs can be totally different depending on which industry you go into, but for me fintech was a dream mostly because I’m a nerd at heart – I wanted to study Finance, while dad insisted on Computer Science, so I pursued both. You can say I had an advantage, and you’d probably be right. But remember: luck is where preparation meets opportunity. As a computer science graduate my only prospects at the time were to be a programmer, a SysAdmin or an IT/tech support, none of which I felt passionate about when I graduated back in 2012, so I didn’t pursue software engineering route for long, which could’ve been a mistake in retrospect, but I’m pretty happy with where I am, since I was a frustrated programmer. So what can you do to increase your chances of becoming a PM?
Make a horizontal shift inside a company
My experience has been making a transition within a company, which in my opinion is the best way to get “in”, if you don’t have any direct or interchangeable experience. Even though as a Technical Program Manager I had very similar overlapping responsibilities with a PM, not being able to put “Product Manager” in my resume didn’t make me a desired PM candidate in any company. Startups don’t want a PM without experience, since either their CEO is pretty much a PM or because they actually want a seasoned PM who can take them to a seed round or series A/B/C/etc. Big companies don’t want a non-experienced PM because even they want someone who can bring outside expertise and value to their business, and they have plenty of internal employees who already know the business and are more than willing to step into junior/associate PM role as soon as something opens up.
Which brings me to the point of why making a horizontal shift within an established company is the best option. You can choose a company you feel passionate about, whose product you’re excited about, who you’d want to build and/or expand the product for. You get into it – with your specialty (if you don’t have one – there’s almost always an entry-level option, like customer service, techsupport, or other business/operational teams) and carve a way into PM from there. It may not be a direct way, it may seem longer, but there are advantages. Not only you can build rapport within the company, you’ll have access to the people, teams, users, resources – who are already building or using what you want to build, and you can learn from them directly, slowly integrate into their work lives by being useful, by accumulating knowledge. I didn’t want to just get the new title and be thrown into improvising with no one to learn from or lean on. Bigger or established companies have senior staff who can provide support and guidance, more/better tools and resources to use and get really good at, instead of free/cheaper alternatives. You might say it’s missing the thrill of “sink or swim” in a startup – but there’s already plenty of challenges being a PM, and worrying about spending extra dollars on user research tools, buying Lucidchart for your diagramming needs with the team or premium Slack subscription to access older messages is not something you’d want to have extra headspace for.
Of course if you get a chance to be a PM at a startup – go for it, that’s exciting regardless, and you’ll learn a ton from the get-go.
I definitely think having a technical background is advantageous to start with. Because you’d be spending a lot of time with engineering teams (any or all can apply from scrum/agile teams to InfoSec, DevOps, Infrastructure, QA, etc), you need to understand what is being built behind the pretty looks of the UI/UX/product designs. If you can speak the same language with the team who’s building things with you, you’d be more respected by them, know the capabilities and limitations of the system, understand and even project the estimates and timelines for new features and bug fixes, which in turn helps you prioritize the work more efficiently, ahead of or bypassing having never-ending team meetings, which saves money and time, which again builds up more trust and respect in you as an expert in everyone’s eyes.
Being technical doesn’t necessarily mean you know how to code (though my engineers rejoice whenever I push a git commit or even comment on a pull request), but it does mean you take an interest or two in understanding the system architecture and design instead of letting it go over your head completely. Maybe take some programming 101 or just ask an engineer at your company to walk you through some of the topologies. An hour spent learning something new can go a long way.
This may have been one of the biggest advantages I had to even get the opportunity for making a switch to PM – I was curious enough to get into nitty gritty details, specific technical solutions applied to the financial world: why our system had to be immutable (you don’t want anyone manually deleting credits or debits from your account), how it can scale with transactions volume growing, how we can deal with duplicate records and correct erroneous ones. I could answer most of the questions on behalf of engineers or PMs about what the capabilities were and how the system worked, so nobody doubted my ability to pick up the work immediately, at least from the technical side, which of course isn’t enough by itself.
Know your user
Everybody knows this – you’re building the product for your customer, so you need to ensure you’re solving a real problem. However it’s not enough to just know who your customers are or what they do. It’s important to know exactly what their problems are, meaning you actually know how to do their job/task/activity and feel the pain so much you really want to solve it for yourself to avoid feeling it.
This was my main gap when I became a PM – I previously had very little interaction with the users, so I immersed myself in learning how to do their job. I shadowed everyone in finops/finance department, learning their macros in endless Excel spreadsheets, all their reports and daily reconciliations, all the data sources they used – from bank records to internal Tableau dashboards – until it made sense. It was very confusing at first, my head was hurting from all the numbers. But it always comes together if you put effort. And people are patient with you if you’re frank upfront about where you are and if you show them dedication. When I started, first thing I told all my stakeholders was I may not have 10 years of finance or PM experience, but I’ll do everything to learn as fast and as much as I can – and that I’m 100% committed to delivering the best product for them. I think just that one sentence – which I meant with all my heart – won theirs.
So I kept at it until I was able to perform my users daily job – yes, with all the spreadsheets and bank statements and crazy macros and pivot tables – and now I can even go to the extent of saying that even though I stay in ProdEng department, my inputs and knowledge are highly valued in operational payments, capital markets and finance departments.
This skill which can be applied to any industry you’re in and which you can learn if you’re persistent, creative and open – will gain you so much confidence and trust from your users and stakeholders that they’ll see you if not as an expert in their own field, then at least their equal, someone who speaks their language, who totally “gets” them and who can defend and act in their interests. You don’t actually need to wait till you become a PM to start doing this – the sooner you become an “insider” the easier it is to make you a PM in that field.
Learn the product
This one may seem like a combination of the previous two points, but it’s applicable if you’re actually working at the company you want to make a PM transition within. Knowing the ins and outs of the product as it is and as it evolves helps build the confidence in you that you know your stuff. Sometimes even engineers forget how parts of the system work, even though they built it – because they’re busy thinking about engineering new things or refactoring old things, so if something breaks or needs to be improved – you’d be the one responsible for ensuring it’s done. Knowing where to look for the right answer, knowing bugs, features, workarounds, limitations and possibilities – this is what engineers and stakeholders turn to a PM to, so knowing the product goes without saying – but it helps to get that job if you already know it while you’re not a PM. Choosing between an outsider who has to learn about it from scratch and someone internal who knows it very well may not be the only consideration, but it’ll give you a way better chance than if choosing between an experienced outsider PM and a non-experienced insider who doesn’t know the product either.
The biggest reasons I got the PM position was because I was working on launching our massive platform in a live environment, requiring no interruption to existing flow, and we’re talking about millions of dollars that come in and out through the system – so our release plan had a precision of a rocket launch, which I was responsible for putting together. And because it was a big deal – C-level execs and all the company was watching us do it over Zoom while a small group of us sat over our laptops in a stuffy conference room deep into the night (we popped champagne after midnight sometime). Exposure to top management and the high profile project gave me an advantage, but I was prepared – I was dedicated to the product regardless of the title, and it was noticed. The transition happened well after that launch day, but it was the tipping point, and when opportunity finally came I was the first to be considered.
I mentioned that during chaos there’s an opportunity for change, and now amidst uncertainty, people getting laid off, companies shutting down there’s a big restructure everywhere. So one can choose to be desperate and fearful, or stay hopeful and focused on creating and seeing opportunities. Positions previously filled are freed up for new faces when time comes, new and old companies rise up solving new needs, pivoting old focus to more pressing demands, everyone will rethink their priorities – from individuals to corporations. So now is a good time to learn new skills, to be curious, to be useful especially in areas looking challenging, to stay relevant in this ever-changing unpredictable world. Stay open and focus on what you want – and you may thrive in the toughest times.