If you’d told me back when I was building advanced graphics and AI modules for AAA games, that those foundational skills in problem-solving, innovation, and systems optimization would one day lead me to pioneer cloud storage solutions for enterprise SaaS, I might have been skeptical. Back then, cloud computing was still in its infancy. I was super into coding and moving away from a programming role was the last thing on my mind. 15+ years later, my career has taken me across console gaming, Smart TVs, and cloud cost optimization, and through it all, one shift was the hardest to navigate: moving from engineering to product management.
When I first transitioned, I thought (or had heard) product management was about being the ‘CEO’ of the product – where you would get to own every aspect around the product development. The reality was quite different—much of it involved navigating trade-offs, aligning stakeholders, and ensuring engineering could deliver something valuable within constraints. That shift—from execution to strategy—was harder than I expected.
Where My Engineering Background Became My Advantage
Some skills from my engineering days carried over surprisingly well:
- Systems Thinking: Whether it was figuring out how to build a ‘depth-of-field’ effect for SpellForce, or getting the best performance on the Samsung SmartTV, the ability to break down problems into their fundamental components has always helped. A product is more than just a collection of features. It’s an interconnected system where every decision has downstream effects.
- Debugging at a Higher Level: At my first job as an intern at a gaming studio in Scotland, one of the things I learned was that the first bug you find is rarely the real problem. In product management, this translates to asking deeper questions: Is churn because of missing features, or is it really because onboarding is confusing? When customers say something is high priority for them, is that feature request truly necessary, or is there an underlying workflow problem?
- Bridging the Gap Between Engineering and Business: Whether at Apptio or at KPIT, working on data integrations for IT and finance or building the ecosystem for connected vehicles, meant explaining technical constraints to business leaders and business priorities to engineers. Being able to translate between the two worlds is a huge advantage for a technical PM.
The Pitfalls of Thinking Like an Engineer in a PM Role
Of course, not everything translated smoothly. Some habits from my engineering days worked against me:
- Over-Indexing on Tech: Early on, I would at be guilty of pushing for highly technical solutions simply because they were technically elegant. But product decisions aren’t about solving algorithm challenges. Sometimes a simple, low-tech solution is the best way forward.
- The Bias Toward Complexity: As an engineer I loved building complex systems and as a PM, I often caught myself over-engineering workflows. At Intuit, I worked on automating financial workflows for SMBs, and I had to unlearn the instinct to build fully automated solutions when a manual workaround was good enough for most users.
- Letting Go of Urge to Code: The hardest lesson? Realizing that even if I could jump in and fix a bug, that wasn’t my job anymore. My role was to set direction, not to be another engineer.
Decision-Making: When to Trust My Technical Instincts
Some PMs avoid getting into technical details—I don’t. My engineering background helps me know when to push back:
- When an Estimate Feels Off: As a PM, I’ve seen cases where an engineering estimate seemed high—not because the work was complex, but because the engineer was being overly conservative or playing it safe with the delivery timelines. Sometimes, it just takes the right questions to uncover a more realistic scope
- When a Solution is Over-Engineered: Engineers sometimes propose solutions that are more powerful than what customers actually need. Understanding the tech lets me identify when we’re overcomplicating things.
- When Security and Scalability are at Risk: I know that technical debt around performance, security, and scalability is real. I have no hesitation in prioritizing these over a flashy new feature that might look good in a demo but cause problems down the line.
What I Wish I Knew Earlier
When I first moved into product management, I assumed being data-driven meant obsessing over numbers—feature adoption rates, retention metrics, activation percentages. If the numbers looked good, the product was doing well. Simple, right? What I didn’t appreciate at the time was that numbers alone don’t tell the full story. A feature could have high adoption but still be frustrating to use.
The real insights often come from talking to customers, watching them struggle with workflows, and asking the right questions.
At Intuit, for example, we worked on automating financial workflows for small businesses. The goal was to reduce manual effort and improve cash flow management. So we built a system that let users set up complex automation rules for invoicing, payments, and reminders. The logic was sound—automation meant fewer missed payments. Hence better financial control. But when we looked at usage data, we noticed something odd: initial adoption was high, but most users weren’t going beyond the default settings. The 30 day retention was taking a nose dive. Through customer interviews, we realized the real problem wasn’t a lack of features. It had to do more with how customers were perceiving workflows. Users were hesitant to hand over control to an automated system without knowing exactly what it would do. They were concerned about any negative impact it might have on the end customer relationship. So, instead of adding more customization options, we shifted our focus. We improved onboarding and transparency into how automation would behave. That change made a bigger impact than any additional functionality ever could.
Another hallmark of a great / impactful product manager is Influence. Unlike an engineering manager or a marketing lead, a PM doesn’t actually run any team. You don’t own engineering, you don’t manage design. You control neither sales nor customer success. Yet, you’re expected to bring all these functions together to build and launch a product and ensure it meets the success criteria. That means you can’t rely on authority—you have to build influence.
Influence isn’t just about having the right data or a well-reasoned argument (of course these help). It’s about understanding what different teams care about and framing things in a way that resonates with them. Engineers might not be swayed by customer pain points alone, but if you show them how an issue leads to unnecessary support escalations, they’ll listen.
Probably the hardest lessons to learn was that product management isn’t about building everything you can—it’s about choosing what’s actually worth building. Almost any customer problem can be solved with code. But not every problem needs a technical solution. Sometimes, a process fix, better documentation, or a simple workaround is enough. It’s easy to get caught up in building complex features just because they’re possible, but if they don’t meaningfully improve the user experience or drive business impact, they’re just wasted effort. A big part of being a PM is knowing when to say no to an idea that sounds good on paper but won’t really move the needle.
Looking back, moving into product management was one of the best career decisions I’ve made. It hasn’t always been easy—learning to influence without authority, making decisions with incomplete data, and letting go of the urge to just fix it myself took time. But the trade-off has been worth it. As an engineer, I was solving interesting technical problems, but as a PM, I’ve been able to shape the direction of entire products, drive meaningful impact for customers, and work across teams in a way that constantly challenges me.
For engineers considering a move into product, my advice is this: If you enjoy solving problems at a broader level, thrive on collaboration, and are willing to embrace ambiguity, product management can be an incredibly rewarding path. For me, it’s been far more satisfying than just shipping great code.