I learned this the hard way, and I wish someone had told me before I tried.
There’s a version of the product manager career path that used to make a lot of sense. You came out of consulting, you had sharp frameworks, you could run a room, you knew how to structure a problem and present it cleanly. That was enough. Product was a coordination role, and coordination was something consultants were trained to do.
I believed that version of the story. For a while, I think it was even true.
It isn’t anymore.
What I got wrong
When I came into product management from a consulting background, I assumed the core skill was synthesis, taking inputs from engineers, designers, and stakeholders and turning them into a coherent direction. And that is part of it. But I was treating synthesis as a substitute for understanding, and those are not the same thing.
What I didn’t realize was how quickly your credibility erodes when you can’t go under the hood.
Writing a PRD that your developers trust requires more than good formatting and clear acceptance criteria. It requires knowing what’s actually hard. It requires understanding the architecture well enough to know when a feature that sounds simple is actually a six-week nightmare, and when something that sounds scary is a two-day config change. If you don’t know the difference, you’re not writing a roadmap. You’re writing fiction with deadlines attached.
I dug myself into a deep hole because I had surface-level knowledge of how the product worked and I tried to operate like that was enough. It wasn’t. And the developers knew it before I did.
The thing consultants aren’t told
Consulting gives you a very specific kind of confidence. You’ve presented to C-suites, you’ve synthesized ambiguous problems under time pressure, you’ve managed up and across and sideways. You come into product feeling prepared.
But there’s a skill consulting doesn’t train, and in some ways actively works against: the willingness to not know something, to sit with a codebase or a system diagram and admit you don’t fully understand it yet. Consultants get rewarded for projecting command. That instinct will get you killed in a technical product role if it stops you from doing the work to actually learn the thing.
The consultants actually making the jump into product right now are the ones who got real product exposure while they were still in consulting. Not just advising on strategy. Owning something. Building something from zero to one for a client, being accountable for whether it shipped and whether it worked, learning to speak the language of the developers on the team because that was the only way to get anything done.
If you have that, you can translate it. If you don’t, the gap is bigger than most people think.
What “technical” actually means
I want to be precise here, because the word gets misused.
You don’t have to be an engineer. You don’t have to write production code, debug a memory leak, or design a schema from scratch. But you do have to be willing to get hands on keyboard. You have to be willing to go into the system, look at how things are connected, understand the data model, follow the logic through. You have to be willing to look dumb in front of an engineer and ask a question that probably has an obvious answer, because the alternative, pretending you understand and building decisions on top of that pretense, is so much worse.
The bar is: can you have a real conversation with the people building the product? Not a coordination conversation. A technical conversation, where you understand what trade-offs are actually being made and why.
If you can do that, you can be a genuinely good product manager. If you can’t, you’re always operating one layer removed from the truth, and eventually that gap shows.
The world that no longer exists
There was a moment, and I don’t think it was that long ago, where strong general skills could carry you through a product role, especially at bigger companies with structured teams and clear process. The role was more about alignment and communication than it was about depth.
That window’s mostly closed now. The companies worth working at want people who can do both: communicate and align, and go deep. The bar moved, and it moved faster than most people coming out of consulting have caught up to.
This isn’t a reason to despair. It’s just a reason to be honest about what preparation actually looks like now.
What I’d do differently
If I were talking to someone coming out of consulting who wants to move into product, here’s what I’d tell them.
Find a way to own something technical while you’re still in consulting. Not just the strategy layer, the actual product. Build something, ship something, be accountable for whether it works. That’s the difference between a resume that gets you in the door and one that gets you the offer.
Learn to read the systems. You don’t have to become an engineer, but you should be able to look at an architecture diagram and know what connects to what, look at a data model and know what the product is actually tracking. Sit with the people who build the thing and make them explain it until you actually get it, not until you can nod along.
And let go of the consulting instinct to project command before you’ve earned it. The best technical product managers I’ve met are intensely curious and genuinely humble about what they don’t know. Curiosity plus humility is what closes the gap fast.
I’m still learning all of this. But I’m learning it because I had to, not because someone warned me in time.
Consider this the warning.