How I became a Fintech product manager (without a CS degree)
I’ve been working as a Product Manager at Plaid for just over a year now, which is just long enough to get over the bulk of my imposter syndrome, and to learn the first lesson of being a good PM: if you find yourself repeating a task over and over, automate it!
I get a lot of inbound questions (from students, consultants, or folks working at tech companies in non-technical roles) about how I became a PM without a CS degree. I remember being in that position, and seeing job description after job description listing “CS degree or equivalent technical experience” as a non-negotiable criteria, and wondering whether I’d ever find a home in Product.
Anyway, since I can’t meet with everyone who reaches out to ask, let me download the advice I give to friends-of-friends right here instead. Disclaimer: these are my opinions, not those of Plaid (I just decided to write this, sorry team).
My journey to being a Product Manager
Before Plaid, I was working in Google’s central Business Operations and Strategy team – I worked on a wide range of topics, including product & pricing strategy for Google One, early stage product support for new Nest & Google Hardware products, and some deep analytics on what drives engagement with Google Search. Before that, I worked at Bain & Company – I started as an Associate Consultant out of university and over 3 years was promoted through to the post-MBA role, mostly working on private equity diligence work with a side of retail and consumer products.
I’d dabbled a little in UX Design at an early stage startup, and taken a Udacity Nanodegree in programming, but I’m decidedly non-technical. I studied film, politics and law at university, and spend my weekends knitting and painting instead of side-hustle coding projects. I think Sapiens is a bad book, and wish people read more fiction instead, and if I ever earned Fuck You Money, I’d start a local newspaper.
The truth was that I knew I’d be a great PM with the right team: I had spent 7 years driving company (and product) strategy decisions at Bain & Google, I’d built strong process muscles and knew how to build pitch decks. I’d wrangled cross-functional efforts and convinced stubborn stakeholders that my ideas were Good, even without any organizational authority. I’d worked closely with engineers and learned how to build trust even if I didn’t always get the jokes about bubble sort. And I’m empathetic, think a lot about product design, and care really deeply about outcomes. I’d tested this theory out by working closely with PMs at Google, and kept hearing from them (and their managers) that I’d be a shoo-in for a product role.
But when I looked at the internal process to transfer, I needed to pass a software engineering interview to qualify. I was pretty sure I could learn enough computer science to pass it, but it would take me months of study in the evenings after long days at the office, and I wasn’t sure that the skills I’d learn would actually be helpful in my day-to-day job after I transferred (…how many PMs really use Big O notation on a regular basis?). More importantly, I was worried about what it said about Google’s expectations for what a good PM looks like. If the baseline expectation is “at least as good as an entry-level SWE”, then would I always be a square peg in a round hole? Would my spikes (empathy, design, collaboration, enthusiasm) be valued over people who could identify cutting-edge technical solutions but were nightmares to work with?
After investigating a few teams internally at Google, I ended up talking to startups with a broader definition for who could be a PM and, spoiler alert, signed an offer with Plaid in 2019.
Our product team is an interesting mix. We have team members who:
- have consulting backgrounds like me
- internally transferred from our go-to-market org with deep customer expertise
- joined from Career PM roles at big tech companies, and who bring polish and maturity
- former software engineers who can work closely with eng teams on complicated problems
I really loved the idea that we had a team with different skillsets to cover a range of different problems, and could see where I’d be valued. You want a different skillset for the PM who’s building new ways for big banks to send their data to Plaid than you do for someone who’s trying to identify new niches for new products and experimenting with MVPs to see what finds product-market fit (fwiw, my role at Plaid is the latter). Plaid also has the concept of ‘hiring for spikes’, and I knew they were looking at my potential to change the company for the better, not whether I fit the model of a standard-issue Stanford-CS-degree PM.
I can’t overstate how much taking a role at Plaid was the right fit for me: I felt like I had space to learn the skills I needed to be a good PM, but was given projects that let me stretch my legs and learn about Plaid, Fintech, and how other people at the company solve problems. The team also understood what I was already good at, and trusted me enough to run ahead without oversight. I launched a new feature in my first few months that generates revenue for the company, and have been heads-down on building, testing, and improving a new product this year with a great engineering and design team.
(PS: we’re hiring! Like… a lot. I’m not making this Medium post because we’re hiring, but nevertheless if you’re interested, @ me!)
So what advice do I have for you?
Find ways to prove your product chops in your current role
This is pretty standard advice, but: if you’re trying to make a career shift, it’s usually easier to take the first steps in your current role where you’re already an expert. If you can literally take on a part-time product management role as an ‘extra-credit’ responsibility, that’s great! But you might not have time to do so, or your current team might not be open to it. Instead you might want to take on more project management tasks, or prepare some detailed feedback on a product your company sells and grab coffee with a PM to talk it over.
A tough piece of feedback I sometimes give people is that it might be too much of a leap to get directly from where you are right now to where you want to be. It’s not that common for people to exit directly from a strategy role into a product role – they usually take some interim steps first, like an MBA internship in product, or a strategy role at a tech startup. If you really want to be a PM, you might want to take a longer-term view, and take the role you can get at a company, with an aim to transfer over to the product org in a year or two. I’ve seen this work for BizOps, Strategy, or Chief of Staff roles, and most large companies have a defined process around internal mobility. If they can see your performance reviews and know you’re already ramped up on the company, they might be willing to make a bigger bet with hiring you than if you applied cold from outside the org.
Consider whether product is even the right space for you
This is another hard conversation I have with current consultants – “pivoting to PM” is the new buzzy exit strategy from MBB consulting. I get why: it’s well-paid, interesting, impactful work, and well-regarded for next steps in your career trajectory. But doing something just because it’s sexy isn’t always the right decision. Product Management is genuinely hard – there’s always more work than you can get to, you’re in the business of compromise (between technical ideals and what can actually ship, between what customers want, and what you have space for on the roadmap, between short-term customer love and long-term strategy decisions), and you have no authority to force people to agree with your preferences. If you don’t love it, it’s going to be a rough ride.
There are plenty of other roles for non-technical folks in tech where you can have a big impact:
- BizOps / Strategy: the name “BizOps” hides a lot of vagueness, and there are some teams who use the name but are effectively doing FP&A work. But if you can find the right team, there’s some cool work to do! For example, the OG BizOps team at Google does project-based strategy & ops projects across any org in Alphabet and works only on the highest priority stuff for the company’s leadership. It’s like being a member of a small consulting office with handpicked tech strategy and operations projects. I felt like I got to keep the best parts of my Bain job, but throw out all the worst bits! To be honest, I felt like I tapped out on what I could learn in this team after a few years since it’s practically very similar to consulting process-wise, but it’s a great entry-point into tech if you’re looking for one.
- Chief of Staff: these roles have exploded over the last few years, and also really vary from role-to-role, so you need to do some deep diligence on what the JD really entails. But done right, being a Chief of Staff allows you to add value to a senior leader by helping them manage their portfolio of projects, take some projects off their plate by acting as their proxy, and help them keep an eye on what’s really important at the organization. It also allows you to learn about what it takes for a senior leader to be successful, and hopefully they take time to mentor you to step into a similar role in the future. A good example here is Intel’s Technical Assistant role, where mostly non-technical rockstars received deep mentorship from the most senior leaders at Intel while they helped their bosses with tactical day-to-day tasks. The TA program birthed the next generation of leaders for Intel, and ensured there wasn’t a huge loss of institutional knowledge when the old guard moved on.
- Go-to-market / Growth: I spent less time investigating this, because I was worried about needing to spend time pitching customers (I am decidedly not a salesperson), but with the right mix of talents you could have a huge impact on a GTM organization. I often hear people say “I want to get closer to product”, and one way to do that is to build the product. But another way to do that is to understand how customers use the product, and build a deeper sense of empathy for what it does for them. Some of the most important people at Plaid are in our GTM team, and are tireless advocates for their customers and what features we should be adding to our products!
Many of these are easier next steps from consulting or strategy roles, and are worth considering!
Look for flexibility
I explained this above, but the reason why Plaid was right for me was that it had a more flexible idea of who could be a good fit in Product. For signs that they’ll be open to your background, I’d look for teams where
- someone on the team has worked in consulting, finance, marketing or some other non-CS/non-PM role
- there’s a mix of undergrad / graduate educational backgrounds (e.g. history majors, or law degrees)
- the job description either doesn’t mention educational requirements or explicitly nods to non-technical roles
It’s also important to investigate what a PM actually does at that organization. Maybe they’re open to non-technical PMs because their PM job is a non-technical role! This is often the case at Amazon, where the industry-standard PM work is done by a TPM, and their actual PM role is more similar to a PMM elsewhere. It’s worth considering whether you’d still be interested in a role that’s more about program- or project-management, or where you wouldn’t work directly with engineers.
Network network network
God, I hate that this is on the list. The usefulness of networking really makes it harder for people without connections to the tech scene to break in, which hits folks from non-traditional backgrounds and from underrepresented groups so much harder. When I first moved to San Francisco I didn’t even know where to begin! I’m from New Zealand and didn’t know anyone at the companies I wanted to work at. I ended up cold-calling or applying from job websites, and I now understand how unlikely it was that I got hired that way.
(Not a super fun fact: a few years ago we took down our standard job posting for a while because we’d filled our hiring goals for that year. A director in our team was like “well, we never hire anyone who applies on the website anyway”, and I had to sheepishly put up my hand and identify myself as a website applicant who was insufficiently well connected to get a warm intro. Yikes!)
But unfortunately it remains true that the easiest way to get an interview is to know someone at the company. Most companies have an internal referral program that benefits the employee making the referral if you get hired, so it’s in their best interests to at least submit your CV for review.
If you really don’t know anyone who can immediately help, it can be helpful to look at LinkedIn profiles for people who have the job you want. Do they know anyone you know? Do you have anything in common? You can always reach out directly to see if they’d be willing to chat (although you should understand that they might receive 5–10 of these messages a week and can’t possibly answer everyone), or look for a softer intro through a mutual connection. I have a few friends who found their dream roles by reaching out to company alumni who’d left to take a job in an industry the friend was passionate about. It’s worth a shot, but make sure you stay respectful and understanding of the fact that the person might already be overwhelmed and overcommitted.
In conclusion…
… I don’t think every PM in a team should have my background, and I don’t even think the majority of PMs should be hired from consulting or MBA programs. But I do think there’s a space for more flexibility around who to hire, and what kinds of projects they could contribute towards. “If all you have is a hammer, you’ll assume everything you see is a nail” is an adage for a reason, and I saw Google slipping into this trap a lot. Solely hiring technical PMs (& promoting / rewarding them based on technical difficulty) led to some weird outcomes: building something because it’s a cool technical solution rather than being what a user actually wants, or re-launching the same apps over and over again instead of working to improve something users have already adopted.
Empathy, curiosity, and persistence are just as important to have in your toolkit too as a company! If you’re applying for PM roles without a CS degree, keep in mind that you could add a new spike to the product team by bringing a new perspective or new way of solving problems. They’d be lucky to have you! 😘
