Product management is a relatively recent discipline, young enough that the definition is still a bit shaky and we see occasional reactionary questions. (“What would you say you do here?” was directed at a PM after all.) When my PM career started the only formal training was Practical or SVPG; now I meet intern candidates and MBA students who have taken Product Management classes at top-ranked universities. I suppose that means there’s a level of formalization past the business books in the airport, though I’m not positive I’ve seen outcomes from that formalization (to be honest, few entry level product roles seem to have survived the current downturn). That said, formal education as a PM is not the only or even normal path into this role in my experience. So, what is?

I’ve met a lot of product managers at a lot of stages in their careers. I haven’t conducted formal research, but I have formed some aggregate opinions based on experience. The PM role is glue work that shifts to meet the needs of the teams they work with, and PM’s are not one-size-fits-all interchangeable units. PMs are software people who work with people, PMs are entrepreneurs with lower risk appetites, PMs are puzzle lovers where the pieces are projects, people, and time. Titles are fuzzy, roles are ill-defined, the rule book is locked away in someone’s filing cabinet on a sunken ship and success or failure are remarkably hard to measure or predict.

Charity Majors writes “this is an apprenticeship industry”, and while she was referring to the software engineering side, it’s even more true of the other roles in the “making software” world. The product manager’s job is constantly changing and the only way to learn it is by watching, then practicing under guidance. I couldn’t say how long a SWE apprenticeship should last, but I can’t imagine a product apprenticeship being less than a year (and two wouldn’t surprise me). Entry points into the product apprenticeship do not look like the Vegas-level STEM-at-a-top-school software engineer’s path. I think these are the most common paths to (and from!) the field of product management.

Where From?

School

In my career I’ve met maybe three dozen PMs who came into the role from school, a number that is mostly interns. My number is higher than most because I’ve been involved in or the sponsor for PM internship programs. Most have been brilliant people who work hard and bring their full selves to the job, but I can only think of seven from that path who are still employed as PMs. Five of them were from masters programs, and three are now senior leaders. Nota bene that an MBA is not a requirement of success: one of those programs was a Masters of Fine Arts, and another candidate got the interview because of their experience as a coach. Out of the remaining pool, maybe half had post-grad work. Lots of computer science and math, some pre-med and pre-law, a few business courses. The final set is a small handful of people who started companies out of school, made connections, and took product jobs after shutting their companies down.

While the school to product career path is not impossible, it’s not simple either. The apprenticeship period is not shortened. Common feedback from successful intern-to-PM hires is that it’s much harder than they expected. Some quotes:

• “Engineering work can be difficult, but there’s a proper way to do things that you just have to understand and follow. Product work is cutting a trail where there wasn’t one before.”
• “I did not realize how little I knew. I had to learn the domain, our product, our competitor’s products, how our developers work, how our customers work. Every time I’ve thought I knew what was going on there was another surprise.”
• “Making the jump from customer needs to engineering or design conversations broke my brain several times.”

Field Engineers

Field engineers, and usually that specifically means sales engineers, are pretty regularly candidates for entry level PM positions. This is the path I took, and I’ve mentored or hired many others along this road. The skill sets are well-aligned: a sales engineer is used to leading without authority, building credibility from scratch, and learning new technologies “on the wing”. If they care enough to understand customer needs and bend the product into fitting them, that’s a very strong signal for product management capability. In an organization where the sales engineer is part of deploying and supporting what they sold, they learn very PM-relevant lessons about delivery. I like to look for SEs that write blogs, maintain content or utilities, moderate user groups.

Good sales engineers are often doing those things because they’re bored out of their skulls. When product market fit is solid and go-to-market pipelines are optimized, the job is just not that hard anymore. Such a company might also decide to keep sales engineer salaries on the COGS (Cost of Goods Sold) side, and hand delivery off to specialist field engineers, drawing a firm line between revenue creation and solution provision. That makes the SE’s job a dull litany of demos, proof-of-value labs, and sales meetings. The pay is good, impact to the bottom line is good, but there’s little influence to the technical direction of the company. If they care about tech, then they’ll be interested in trying their hand in R&D, and since they don’t have the skills to be developers, they ask about PM jobs. Similarly the specialist field engineers in such a split company can feel bored and disempowered, and they too will often look at PM roles.

I may be biased since I took the path myself, but I do think field engineer candidates can be great Product people. However, in my experience the bounce-off rate within a year is fifty percent. While the SE may be bored in sales, they’re also safe and well-compensated. A PM works far more and probably makes less (though this can be complicated by how well the company is doing, compensation plan tax rates, equity holdings, and which sales reps the SE is supporting). A PM often has to jump into things they don’t know how to do, with far less support, where an SE has training options. Pricing, for instance, is not something the SE has to set. Go To Market (GTM) plans are harder to create than execute. Even if the set of tasks is entirely within the former SE’s range, their workload will still go up. There’s no impactful sales engineering meeting where the account manager is not at least peripherally involved and watching their back, and there are few meetings that couldn’t be covered by another SE in a pinch. As a PM for a product, you are a singular resource: sometimes the only person who can cover your meetings is your boss (but if you’re lucky, you might have a dedicated SE to lean on). Your writing requirements go up, too: where an SE’s communication could be mostly verbal, a PM’s is at least 50% written. Consequently, bounce offs: many SEs return to the field.

Software engineers

Software engineers (SWEs) can have a similar level of boredom with their role, plus a sense of isolation in some company’s cultures. Given some time to understand fitting problems to solutions and get bored with the continual pivoting from yesterday’s hotness to tomorrow’s, smart people can be left asking if this is all there is. There’s management, but leading people isn’t for everyone. It’s not uncommon for a mid-career SWE, team lead, or team manager to look at product management and think “that looks fun.” These transitions can be a great fit! I learned a tremendous amount from a leader whose career regularly flip-flopped from engineering to product leadership, and my most productive partnerships are with product-minded engineers. Being “technical” isn’t required, but a product person with strong tech chops has an edge.

On the less awesome side, the SWE career path can lead to some product thinking gaps. By no means guaranteed, but some may need coaching for humility, writing, and the value of inaction.

• Humility: Imagine that you had a natural talent for math and puzzles, so your teachers and parents recommended software engineering. Imagine that you worked hard, got competitive offers from top schools, and were able to select a full ride or solid discount for a name brand education. Imagine competitive offers for internships, some time being bored at name brand tech companies, some time in challenging but fun smaller teams. Some people on paths like this can come away feeling that hard work is all that is necessary to solve problems. Sometimes hard work is not enough to overcome structural problems, and failing after doing your best can teach humility (but doesn’t always!). People lacking humility may be susceptible to bubbles, building the wrong features, or struggling to get along with others. Said differently, sometimes the 10X engineer has not found it necessary to learn how to get along with others.
• Writing: Good product managers write well, particularly in a remote first company. Senior staff or principal SWEs typically do as well, which is great! An early or mid career software person switching to product manager may need to focus on improving this skill, particularly if they’re not using to communicating with executives.
• Inaction: Solving the problem by writing more code is a very easy reflex for a trained SWE to fall into. When changing configuration or changing the problem is a lower risk path, that is often preferable to customer and vendor. Fixing code is great, but deferring or avoiding a quick fix can uncover opportunity for better solutions. Bias to inaction can go too far though: a given product’s’ investment doesn’t continue without an argument.

Where To?

Not everyone can stick a transition to PM. For some, this role is too much and they bounce off. For others, it’s enough: a fulfilling and exciting opportunity to be a critical part of launching something. Some of this group grows into PM leadership roles, while others focus on growing to be more efficient and effective product managers. And for a third group, PM is just a stepping stone, entrepreneur training camp before they try their own thing.