How to Get Into Product Management

I spent the first few years of my career as a software engineer before I discovered product management and made the move into the space.

The first PM I worked closely with was technically amazing but not as good at communicating the important stuff to the people that needed to be informed. I watched them get replaced by someone who was good at both. That's a lesson for life.

Product management wasn't something you trained for back then. It was still new, less defined. You fell into it sideways, usually from engineering or design or business, and figured out the gaps as they became obvious. Now it's a bit different as there are unlimited courses, bootcamps, certification programs and entire communities devoted to the question of how to break in.

I'm not sure most of it is pointing at the right thing, honestly.

What the Job Actually Is

Before you figure out how to get into product management, it helps to understand what you're actually getting into. Not the version in a job description or a LinkedIn post, but the day-to-day of the role.

You're responsible for figuring out what to build, why, and in what order, without usually having direct authority over the people who do the building. You sit between engineering, design, the business and the customer, and your job is to make sure everyone's working on the right problem. The reality of it, though, is that most of the job happens in the gaps. In calls where nobody quite agrees on the problem. In reviews where the data says one thing and the stakeholder wants another. In decisions that have to get made before you've got the information you'd like. The product management FAQs is a good starting point if you're still trying to get your head around what the role actually involves before you commit to going after it.

What Actually Makes Someone Good at It

I've hired PMs and I've helped companies hire PMs, and the gap between what people emphasise in applications and what actually makes someone successful in the role is bigger than it should be.

The skills everyone lists - data analysis, roadmapping, stakeholder management - those are learnable. The harder question is whether someone can hold ambiguity without reaching for the first available answer. Whether they can disagree with someone who has more authority and do it without making it personal. Whether they can actually listen to users and hear what they're not saying.

There's a specific quality that I struggled to name for a long time. What makes a good product manager gets at it, and it's not the skills list. It's closer to how someone moves through uncertainty, which sounds vague until you watch enough people do it badly.

Related to this: the willingness to share a half-formed idea, the kind that sounds dumb before it sounds good. I've watched smart people kill potential insights before they've had a chance to breathe because the idea felt too raw and the room felt too important. Being willing to share your stupid idea is actually a skill, and it matters in product more than almost anywhere else, because the problems worth solving rarely look obvious when you first find them.

Coming From Another Role

Most PMs didn't start as PMs. They came from somewhere - engineering, design, consulting, data, customer success. That origin story matters more than people give it credit for, because the thing you bring from your previous domain is what makes your product judgment real rather than theoretical.

I came from engineering. Seven-ish years in. The transition was disorienting in ways I wasn't expecting: the feedback loops are slower, the wins are harder to point to, and you spend a lot of time in conversations where nothing is actually decided. The seven lessons I learned moving from code to product are mostly things I'd have liked to know earlier rather than things I figured out with any particular intelligence.

The most underrated thing about coming in from engineering is that you can actually talk to engineers. Not just in the sense of understanding vocabulary, but in the sense of knowing what it feels like to be asked to estimate something with three pieces of missing information. That context changes how you write specs, how you run planning, and how you respond when something takes twice as long as expected.

Coming from design or customer success carries its own version of this. The channel matters less than whether you've been close enough to real problems that you've developed some feel for them.

Getting In Without Prior Experience

This is the question everyone has. How do you get PM experience when every job listing asks for PM experience?

The short answer is that you build it wherever you are. If you're an engineer, you pick up more of the discovery work. If you're in customer success, you start documenting patterns across support tickets and taking them back to the product team. You find the problems that aren't quite anybody's job and you do something about them.

The shift that matters is moving from executing tasks to owning outcomes - and the hard part is that most job titles don't map cleanly onto that distinction. Getting into product management with no prior PM experience goes deeper on the practical side: what to build, how to frame your experience, and what hiring managers are actually looking for when they say they want someone with "product sense" when they may not be entirely sure themselves.

Understanding What Interviewers Are Looking For

A PM interview isn't a test of knowledge. It's a test of how you think through problems in real time, how you frame tradeoffs, how you handle a prompt that has no clean answer. Most people preparing for one study the frameworks and miss the point.

What interviewers are actually looking for when they hire product managers is written from the other side of the table. Worth reading it once for the framework and once as a checklist of the things candidates most commonly get wrong, which are usually not what they expected to get wrong.

Early Career Development and Mentorship

The first year in a PM role is different from every year that follows. You're still building the mental models, still finding out what you don't know, still learning which instincts to trust. It's also the year where mentorship has the most leverage.

I'm not talking about formal programmes - those can be useful but they're not the main thing. What actually helps is finding someone who's a few steps ahead, who works in a context close enough to yours that their advice translates, and who will tell you the truth when your thinking is off. Mentorship for product managers covers how to find that person, how to make the relationship useful for both sides, and what to do when nobody in your immediate network fits the bill.

There's more practical early-career advice in tips for aspiring product managers - the kind of things that are obvious in retrospect and that most people have to learn the slow way.

The Longer Game

Product management is one of those careers that compounds in a way that's hard to see from the outside. The first couple of years are mostly about learning to work in the role. The next few are about developing judgment. After that, the question shifts from whether you can do this to what you actually see that other people don't.

Most of the advice on breaking in is focused on the first phase. That's useful, and necessary, but it's worth keeping in perspective. Getting in is actually the easy part, more or less. Getting genuinely good at it takes longer than most people expect, and the skills that end up mattering most at senior levels aren't the ones you study to get hired.