In June 2017, after four years as a software engineer at a telecom technology company, I left to do an MBA at XIMB. My plan was to come back as a product manager. Two years later, I joined a large B2B marketplace as an Assistant Product Manager. That transition — from writing Java code to managing a millions of daily active users mobile product — was the most challenging and most rewarding shift of my career.
This is the unfiltered version of how it went.
Why I Wanted to Make the Switch
I didn't hate engineering. I was good at it. But somewhere around my third year at the telecom tech company, I realised that the questions I found most interesting weren't technical. Why were users dropping off at this step? Why did a large telecom carrier need a different segmentation model than a leading telecom operator? What would happen to engagement if we changed the ad delivery window from post-call to mid-call? These were product and strategy questions, not engineering questions. And I wasn't in the room where they were being answered.
I wanted to be in that room. The MBA was my path to get there.
What the MBA Did — and Didn't — Teach Me
The MBA at XIMB gave me frameworks: Porter's Five Forces, Jobs to Be Done, unit economics, go-to-market strategy. It gave me exposure to marketing, operations, and finance that I'd had zero grounding in as an engineer. That cross-functional literacy has been invaluable as a PM.
What the MBA didn't teach me was how to actually manage a product backlog, write a PRD that engineers respect, or handle a live production incident as the person responsible for the product. That came from the job itself.
What I wish I'd done during the MBA: Interned at a product company, not a consulting firm. The case study methodology is useful, but there's no substitute for shipping something real during your transition window.
The First 90 Days as a PM: What Hit Me Hardest
Joining the B2B marketplace as an APM, I expected my engineering background to give me a significant advantage. In some ways it did. I could read code, understand API contracts, and call out when an "impossible" estimate was actually possible. Engineers respected that I wasn't hand-wavy about technical constraints.
What I didn't expect was how hard the people part would be. As an engineer, I executed. As a PM, I had to influence without authority — getting engineers, designers, QA, and business stakeholders aligned on the same direction, without being able to tell any of them what to do. That muscle takes time to build.
The other thing that hit me: the ambiguity. In engineering, success is binary — the feature works or it doesn't. In product, you're making judgment calls under uncertainty every day. Did this metric improve because of the feature we shipped, or because of a seasonal effect? Should we fix this bug now or wait until after the next release? There's rarely a clean answer.
What My Engineering Background Actually Gave Me
- Technical credibility with engineering teams: I didn't need someone to translate the architecture diagram. I could read it, ask the right questions, and catch gaps before they became production issues.
- Realistic estimation instincts: I've been on the other side of a PM who underestimated complexity. I knew when a "simple" feature was actually three months of work, and I could make that case to stakeholders.
- Debugging mindset: When a metric moved unexpectedly, I approached it like a bug — systematically isolating variables, forming hypotheses, testing them. This made my data analysis sharper than many PMs without technical backgrounds.
- Vendor and API evaluation: When we were choosing third-party tools or evaluating new integrations, I could do a technical due diligence pass myself. That saved significant time and reduced dependency on engineering for early-stage assessments.
What I Had to Unlearn
The "I'll do it myself" instinct. In engineering, if you want something done right, you do it. In product, your job is to make sure the right people do the right things. Taking over the implementation when you disagree with a technical approach is the fastest way to destroy trust with your team.
Optimising for correctness over speed. Engineers (rightly) care deeply about getting things right. As a PM, sometimes "good enough and shipped" beats "perfect and delayed." Knowing when to push for speed and when to insist on quality is a judgment call that took me a long time to calibrate.
Thinking in solutions, not problems. Engineers are trained to move quickly from problem to solution. Good PMs spend much longer in the problem space — talking to users, questioning assumptions, making sure they understand the real root cause before proposing anything.
Advice for Engineers Considering the Switch
- Get closer to the customer now, while you're still an engineer. Attend user research sessions. Shadow a support call. Read customer feedback tickets. Start developing the habit of thinking from the user's perspective.
- Document your product instincts. If you have opinions about why a feature should work differently, write them down. What's the problem? Who has it? How do you know? This forces you to think in a PM's framework before you have the title.
- Find a PM mentor. Before my MBA, I spent time with a PM at the same company just asking questions. That exposure shaped how I thought about the role far more than any course did.
- Don't let your technical identity become a crutch. Your engineering background is an advantage, not your whole identity as a PM. The best PMs I've met have deep empathy for users, not just for code.
Seven Years On: Was It Worth It?
Without question. The product manager role sits at the intersection of everything I find interesting — technology, human behaviour, business strategy, and team dynamics. Every day is different. Every product decision is a small bet on what matters.
The engineering background doesn't define me as a PM, but it shapes how I do the job. I speak both languages — the language of the business and the language of the codebase. In a world where products are increasingly technical and technology increasingly shapes business outcomes, that combination is genuinely rare.
If you're an engineer thinking about the switch — the leap is worth it. Go in with your eyes open about what you'll need to build, and don't underestimate the people skills. But the view from this side of the table is worth the climb.
