From Engineer to Product Manager: What I Had to Unlearn

I came into product management from a computer engineering background, by way of QA and project delivery. I assumed the transition would be smooth — I understood the tech, I understood the teams, I understood how software actually gets built. What I didn't expect was how many of my engineering instincts had to be deliberately unlearned before they stopped working against me.

Correct vs. valuable

As an engineer, an elegant solution is its own reward. You feel the satisfaction of a clean architecture, a well-abstracted service, a bug fixed at its root cause instead of patched at the symptom. As a PM, an elegant solution that nobody asked for is a wasted sprint, no matter how proud of it the team is.

I had to get comfortable shipping the "good enough" version and iterating, instead of chasing the version I'd be proudest of technically. The hardest part wasn't accepting this intellectually — it was resisting the urge to weigh in on implementation details in refinement sessions, where my opinion carried weight I hadn't necessarily earned on that specific decision. Staying in my lane as the person who defines "what" and "why," and trusting the engineers with "how," took real discipline.

Being the smartest person in the room about the solution, on purpose, is not my job anymore

Early on, I'd jump straight to solutions in requirement discussions, because I could usually see the technical shape of the answer before anyone finished describing the problem. That shortcut skipped the part where stakeholders actually get to define the problem in their own words — and skipping that step meant I sometimes solved the wrong problem efficiently.

Slowing down to write a proper BRD or user story, instead of jumping to "here's what we'll build," produced far better outcomes even in the cases where my technical instinct turned out to be right. The process of getting there mattered as much as the destination, because it surfaced constraints and stakeholders I hadn't considered.

"No" is a full sentence, and I owe people a reason, not a negotiation

Engineers are used to solving every request thrown at them — that's often the job. PMs have to say no constantly: to features, to timelines, to well-meaning stakeholders with a genuinely good idea that just doesn't fit this quarter. The skill isn't in avoiding "no," it's in explaining the trade-off clearly enough that people don't feel dismissed.

I used to soften every "no" into a maybe, which just meant I had the same conversation three more times before finally saying no anyway — and by then, trust had eroded because I'd seemed indecisive. Now I try to say it plainly, with the actual reason attached: "not this quarter, because it competes directly with the onboarding rework, and that's the higher-impact bet." People can disagree with a reasoned no. They can't do much with a vague maybe.

Requirements are a translation exercise, not a specification exercise

My engineering brain wanted every requirement to read like a spec: precise, unambiguous, implementation-ready. But a lot of what stakeholders bring you isn't a spec — it's a frustration, a hunch, or a half-formed goal. My job became translating that into something a development team could act on, without losing what the stakeholder actually meant in the process. That's a different skill than writing clean requirements from scratch, and it took longer to develop than I expected.

The technical background wasn't wasted — it just changed shape

If anything, my engineering and QA background is why development teams trust my estimates and my backlog prioritization — I've been on their side of the table, and I know what a vague ticket does to a sprint. But the PM job itself required a different set of instincts than the ones that got me hired into tech in the first place. Recognizing which instincts to keep and which to retire has been most of the learning curve.