From mechanical engineer to Product Manager: a transition diary
I did not switch careers because I was bored of engineering. I switched because I realized I cared less about the bolts than about who was using them and why.
In 2020 I graduated with a B.Tech in Mechanical Engineering from JNTU Karimnagar. In 2023 I started my first Product Manager role. Between those two dates I designed 3D printers, ran a rapid-prototyping team, engineered Lithium-Ion battery packs for B2B robotics, and slowly realized I was the wrong shape for hardware engineering — not because I disliked the work, but because the question I kept asking was upstream of the work.
This post is the version of the "engineer to PM" transition story I wish someone had written before I tried it. The LinkedIn version makes it sound clean. The actual version had three near reversals, a lot of unpaid weekend work, and a turning point that I only recognized as a turning point in retrospect.
Why I picked mechanical engineering in the first place
I did not pick it the way the story usually goes. I did not have a formative experience with a wrench in my father's garage. I picked it because, in 2016, the entrance-exam-shaped logic of Indian engineering admissions told me my rank fit mechanical at a college I could live with. That is the truth, and I think it is the truth for a lot of people who later switch into product. The first career was not a calling; it was a decision made under uncertainty by someone with very little information.
I want to flag this because the "follow your passion" narrative tends to make career transitions sound like betrayals. They are not. The early-career decision was always going to be wrong in expectation. Updating on new information is the appropriate behavior.
Futuristic Labs: where I noticed I was looking past the problem
My first real role after graduation was at Futuristic Labs in Hyderabad. The company was building RIKU, an autonomous cooking robot. I was responsible for the liquid and spice dispensing assemblies — the mechanical components that had to integrate with precision-controlled software actuation, hitting sub-gram dispensing accuracy on real-time cooking sequences.
The work was technically interesting. I designed and built four custom in-house 3D printers (CoreXY and Cartesian architectures) to accelerate our prototyping cycle. I helped establish a vacuum-casting facility. I co-led a five-person team in the rapid-prototyping division. By any objective measure I was succeeding as a mechanical engineer.
But I started to notice that the parts of the work I found most absorbing were always one layer up from the mechanical design. I was more interested in the question "why does the user expect this recipe to dispense in 90 seconds and not 60" than in the question "what bearing tolerance lets the gantry hit that speed." The bearing tolerance was the bottleneck I was paid to solve. The user expectation was someone else's job. I kept sliding into the second question anyway.
Apeiron Mobility: the last hardware role
After Futuristic Labs I moved to Apeiron Mobility in Bangalore as a New Product Development Engineer, owning the end-to-end lifecycle for high-capacity Lithium-Ion battery packs sold to B2B robotics clients (Anscer, RightBot, others). PRD, design, prototyping, scale up. The role was a meaningful step up — I led a team of nine to scale production fourteen-fold for our 10 KW LFP packs.
But the pattern from Futuristic Labs continued. I was good at the engineering. I was better at the parts that were not strictly engineering — talking to the robotics clients about what they actually needed the pack to do, negotiating the tradeoff between energy density and thermal stability with the customer instead of with my own team, writing the section of the PRD that explained why a particular spec mattered to the end user. These were the parts of my week I looked forward to, and they were the parts that had no clear home in the org chart.
Around month nine I started doing two things on the side. First, I read every PM book and blog I could get my hands on — not for the frameworks themselves, but to find out whether the work I was already gravitating to had a name. It did. Second, I started building small software products. The Kelby HTML5 games came from this period. The Formies DTC brand came from it too. I was teaching myself the scrappy end of building products, the part that hardware engineering had insulated me from.
The transition: how I actually got the SpaceBasic role
The honest version of how I got my first PM role is that I applied to maybe forty positions and got rejected from most of them without an interview. The friction was real. Recruiters scanning a resume with "Mechanical Design Engineer" at the top did not spontaneously imagine me as a PM candidate, and I was not yet good at writing the cover letter that bridged the gap.
SpaceBasic was different because the role itself was different. They were building a campus-living operating system with significant hardware integration — flap barriers, biometric devices, network infrastructure on real campuses. My mechanical background, instead of being a liability, was suddenly useful: I could talk to their hardware vendors without a translator, I had calibrated intuition for what a hardware bring-up timeline actually looked like, and I could read a hardware spec sheet without panicking.
The lesson I would generalize from this: career transitions tend to find their first foothold in the seam where your old domain is unusually valuable in your new one. Looking for a generalist PM role from a hardware background is hard. Looking for a PM role on a product that touches hardware is much easier, because you are offering something the typical candidate does not have.
What transferred from mechanical engineering
- · Constraint modeling. Mechanical engineering trains you to think in terms of binding constraints — the slowest joint, the weakest material, the tightest tolerance. Product work has the same structure. There is always a binding constraint somewhere (latency budget, hardware throughput, team capacity, user attention). Identifying it correctly is most of the work.
- · Deterministic vs probabilistic reasoning. Mechanical systems are mostly deterministic; user behavior is mostly probabilistic. The transferable skill is knowing when you are reasoning in which mode. Most bad product decisions come from applying deterministic reasoning ("users will obviously do X") to a fundamentally probabilistic system.
- · Systems decomposition. Breaking a product down into subsystems, identifying interfaces, understanding which subsystem owns which failure mode — these are mechanical engineering disciplines that translate directly to product architecture.
- · Comfort with hardware constraints. When a product has any physical component — IoT, retail, automotive, health-tech — the PM who can read a datasheet and reason about tolerances has a meaningful advantage.
What didn't transfer, and what I had to build fresh
Plenty did not. The hardest gap was user empathy as a working discipline. Mechanical engineering optimizes for objective metrics (load, fatigue, cost). User experience optimizes for something slower and more contested — the difference between what users say they want, what they actually do, and what their actions reveal about what they would want if they understood the choice better. Building intuition for that gap took me roughly a year of consciously running user interviews and reviewing my predictions afterwards.
I also underestimated the narrative load. PMs spend a meaningful fraction of their week telling stories — to engineers about why a feature matters, to leadership about why a roadmap is good, to users in onboarding flows about why they should care. I had been trained to communicate technical facts; I had not been trained to communicate narrative. The hack I eventually settled on: read more non-fiction prose than I read engineering writing, and write regularly even when no one was reading.
Scope negotiation is the third gap. Engineering scope is usually bounded by physics. Product scope is bounded by judgment. Learning when to say "not in v1" without sounding obstructionist, and when to insist on a feature without sounding precious, took more reps than I expected. I still do not do it perfectly.
For other engineers considering this transition
A few things, in decreasing order of importance.
- · Do not wait for the perfect PM role to apply. Take the role that touches your domain. The general PM job is harder to get from outside the field; the specific PM job at the intersection of your old domain and a new one is much more tractable.
- · Build small products on the side. Not for the portfolio. For the muscle. Shipping anything end-to-end, even a weekend HTML5 game, teaches you things about scoping, pricing, and listening to users that no amount of reading will.
- · Reframe your resume around outcomes, not titles. "Led a team of 9 to scale production 14x" reads as PM work. "New Product Development Engineer" does not. The underlying work was the same; the framing was different.
- · Expect a real pay reset in the first PM role. The PM trajectory recovers quickly but the entry point usually does not match the engineering title you are leaving. Plan for it financially; do not let it talk you out of the move.
Closing
Two years into the PM career I do not regret the move. I also do not wish I had made it earlier. The mechanical-engineering years are load-bearing in a lot of the work I do now — the hardware integration at SpaceBasic, the systems thinking at Gamezop, even the constraint modeling that goes into something as small as a recommendation engine. The two domains compound. The trick is recognizing the compounding early enough to lean into it instead of treating the first career as something to escape.