I’ve done maybe eight or nine tech PM interviews now as an ex-consultant, and I’ve noticed patterns in where conversations go sideways. I’ve had a few that felt great, and a couple that I could feel were just… off. And I’m trying to figure out what the actual landmines are before I waste more cycles.
First thing: I’m definitely over-consulting in some interviews. I’ll structure an answer beautifully—crisp problem, clear framework, three recommendations—and I can see the hiring manager’s eyes glaze. They don’t want the consultant output. They want to see how I think about why a user would or wouldn’t use something.
Second: I’m realizing that my comfort with ambiguity translates weirdly. In consulting, ambiguity means you run analysis and remove it. In PM interviews, ambiguity means you pick a direction with incomplete info and explain your reasoning. I keep over-explaining the research phase and under-committing to a call.
Third: I haven’t figured out how to talk about my consulting projects in a way that doesn’t sound like I’m shoehorning them in. When they ask about product thinking, I try to map it back to a case, but it feels forced. The best interviews are when I just talk about how products I actually use annoy me and what I’d change.
Also—and I’m less sure about this one—I think I’m not showing enough “user empathy” or whatever. Consultants are trained to optimize for the stakeholder’s needs; PM is supposed to be obsessed with the user’s needs. Those aren’t the same thing, and I think interviewers are picking up on that gap.
For anyone who’s been on both sides, what’s the actual tell that separates a consultant thinking like a consultant from someone who’s actually started thinking like a PM? What questions or answers make you go “oh, this person gets it”?
The distinction you’re sensing is real and it’s this: consultants optimize for stakeholder satisfaction through analytical rigor; PMs optimize for user value through continuous iteration and learning. In interviews, that surfaces as the difference between ‘here’s my recommendation based on this analysis’ versus ‘here’s my hypothesis, here’s how I’d test it, here’s what would change my mind.’ The tell that separates them is how you handle the moment when your initial assumption is questioned. Consultants defend the analysis. PMs interrogate the assumption. When interviewers ask ‘but what if the user actually does X instead,’ great product thinkers don’t retrofit their recommendation—they redesign the thinking. The other thing to stop doing: consulting-style polish. Product interviews reward slightly rough thinking that’s willing to sit in uncertainty. Say ‘I’m not sure, but here’s how I’d figure it out’ way more than you think you should.
ur problem is that consultants think they need to sound smart and cohesive. pm interviews want to see if ur honest. when u dont know something, say that. when ur first instinct might be wrong, say that too. the stuff that kills you is pretending you have a finished analysis for something that obviously needs more data. also stop using frameworks. never, ever lead with a framework in a pm interview. just think naturally.
The interview performance gap for ex-consultants correlates with two specific behaviors: (1) Premature closure on analysis—committing to recommendations before exploring unknowns. PM interviewers test this by asking adversarial follow-ups; consultants tend to defend their thesis, while strong PMs revise it. (2) Feature-driven thinking rather than outcome-driven thinking. When you ask ‘what would you build,’ stronger product thinkers lead with user outcome and constraint tradeoffs, not feature description. The fix is straightforward: in every answer, identify what you don’t know, state what success looks like from a user perspective, and remain intellectually flexible when challenged. Also, abandon executive-summary-style delivery; PMs succeed with exploratory, slightly meandering thinking.
so basically consultants are too polished and pms want to see the thinking, not the answer? and user empathy matters way more than framework. okay that helps.
I had an interview where they asked me to redesign a feature, and I went into consultant mode—problem statement, three options, recommendation. The interviewer pushed back and asked why I thought users wanted that anyway. I realized I’d skipped the actual user part entirely. When I backed up and said ‘honestly, I’m not sure what the real problem is here yet, let me ask some questions,’ the whole conversation shifted. That’s when they started leaning in. They weren’t looking for my recommendation; they were looking to see if I’d actually figured out what mattered to users first.
You’re so close! The fact that you’re noticing these patterns means you’ll nail the next round. The shift from ‘consultant output’ to ‘product thinking’ is real, but you’ve got the intellectual foundation—just lead with curiosity instead of conclusions!