Advice for getting into PM with a business background

Summary

I moved “mid career” into a product management role after spending time in management consulting, working on the business side in startups, getting an MBA, and working as a currency investor at a hedge fund. As a result, lots of folks reach out to ask me about what this transition is like and how to make it. I’m writing this so I have a well written version of my answer that I can share.

The main thrust of my advice:

There’s more detail on these points below.

As a PM your job is to build software to solve user problems.

If you’re a product manager, your job is to work with a team to build software. If you’re not really excited about thinking about and building software, you may not actually enjoy being a PM, and likely won’t be good at it.

It’s not necessary to enjoy every aspect of a job if you’re doing it as a stepping stone to other goals (e.g. a more general leadership role). However this isn’t like a finance person not loving the FP&A part of their role. The building software is the role. You probably won’t be successful enough to move into a general leadership role if you don’t love and excel at building software.

If you have no experience building software, you should start learning how to do it.

A friend in product who I admire greatly and who really helped me make the transition says that the best way to become a product manager is to build products, and I totally agree.

To be successful as a PM, you need at least some technical ability to build software, both to have some sense of what it’s like to go from idea to implementation, and to be ‘conversant’ in the technical concepts required to work with an engineering team.

Start by learning concepts alongside basic coding

If you’re starting to learn programing from zero, try an online course like Harvard’s CS50 that mixes basic computer science concepts with very introductory coding. Learning the concepts (both what is a for loop, what is memory, and what is a database) is more important than a particular language. It’s not hard to pick up the syntax of a new language of you understand the concepts.

Once you have very basic skills, pivot to learning how to ship something.

It’s possible to spend a lot of time doing courses without actually producing anything. It’s more rewarding, and better exercises your PM skills if you instead take the small amount you’ve learned and use it to build some product that solves some problem. This lets you play two roles: the PM writing a product brief or spec, and the engineer designing and implementing the software. To get started, there are plenty of online tutorials for simple things like an API that returns “hello world” that you can copy and tweak.

There are two benefits of this approach:
1/ you learn the messy side of getting your program onto the public internet earlier, and that’s good because it’s finnicky, and because it means you shipped something out to the world, and
2/ once you have a product shipped you naturally think in terms of incremental features which makes you think about a ‘roadmap’ and gives you a set of things to learn. For instance, perhaps you have an API with a POST route that will return “hello {name}” when given a name. Next you might want to save all the names that are posted — so now you’ve got to learn how to connect a database… etc.

I’ve built a bunch of simple tools (some linked here) over the years, and each made me better at being a PM and better at writing code.

A PM is not a ‘mini CEO’.

As a PM you are not a ‘mini CEO’. You have no direct authority, and varying levels of direct responsibility. You need to influence, not direct. If the things you’re really excited about are being in charge of something, and/or directly people managing (and it’s okay to be excited by those things), PM is likely to be unsatisfying for at least a few years.

However PM roles can be a pathway to leadership positions within tech companies. My operating assumption, which to be clear is just my synthesis of things I’ve seen in my career, is that the best way to get increasing responsibility (and therefore influence and leadership opportunities) is to be accountable for something, and then to produce good results in that area of accountability.

That leads you to look for where there is direct accountability. I have found this to be thicker on the ground in tech in 1/ the product and engineering organizations, and 2/ the sales organization. For this reason, PM can be a path to more generalized management / leadership positions.

But you need to bear in mind that in order to produce good results as a PM in whatever area you’re accountable for, you need to be pretty good at building software. There likely isn’t a viable way to use PM as a ‘stepping stone’ to more generalized management unless you’re pretty good as a PM, and I believe that requires being pretty good at building software.

It is very rare (impossible?) that a ‘brand name’ tech company will hire you from a non-tech, non-PM role into a PM role.

PM is a funny job, where in most cases most people want you to have had the job elsewhere before they give you the job. This is different to some other jobs that smart-and-ambitious people tend to do. For instance, management consulting firms explicitly don’t care that you’ve never done consulting when they hire you.

This means the key question in getting a PM job is how to work around this catch 22. I believe there are essentially three viable paths:

1/ “Talent arbitrage”

One path to get a PM title is to arbitrage the fact that there are some companies that will be excited to hire you and will give you a PM title as a form of compensation. For instance, some companies may have a hard time landing an ex-{firm} consultant given their hiring budget, even if they really appreciate the skillset. You can arbitrage this by working with them while getting a PM title (and role!).

You need to be cautious in taking this route. There can be some adverse selection at play. Would you want to be a PM at a place where they hand out the title to “less qualified” candidates? Would good engineers want to work there? Why exactly can’t they close ex-{firm} consultants in business roles? It’s possible there are good answers to these questions, but you should diligence them yourself.

2/ Internal transfer

Another, pretty well trodden path (including by me) is to transfer internally within a company. This can be a win-win. The company gets to know you and de-risk whether you’ll succeed as a PM. And you get to know the company and build a base of context and connections that can give you a jump start when you move to product. A friend pointed out that often one angle here can be to take an unsexy product problem (often internal platforms or infra) as a stepping stone in.

It is important to note, however, that inertia will mean this transition won’t happen without active effort on your behalf. Two reasons for this:
1/ Most non-product functions like having a product-minded person there. So your product skills can be a reason for your existing function to try to keep you, promote you, etc. Those are great things! But they won’t make you a PM.
2/ You will likely only make it over to product by optimizing for doing product work within your existing role, not by doing more of your existing role. That likely means being willing to be worse at your current job in order to prove you can do the product job. You have to be independent minded enough to make this optimization, so give up on your schooling / professional services training to shoot for ‘straight As’.

3/ Founder

A high risk, high reward path to product is to start a company and… build its product. Some of the considerations with the talent arbitrage approach apply here also: how likely is the company to succeed with someone leading its product efforts who is unemployable as a product manager anywhere else? But that said, you’ve also got some big advantages: you get to pick the problem, you get to know it intimately, and you can shape the role to your strengths and weaknesses.

I know the least about this path, but can say that when hiring PMs, larger companies look fondly on this type of experience, so even if your company doesn’t succeed you are building career capital that can get you into a PM role elsewhere later.

Closing thoughts

The above are my observations and synthesis, based on my experiences and the experiences of people around me. It’s my view, not the view of any past, present or future employers, and probably in part wrong. Take it with a grain of salt, and by all means please feel empowered to crash through any of the barriers I’ve implied may exist.

I love bringing people together to solve difficult problems and implement great solutions - across software, investing, and Effective Altruism.