From Engineering Projects to Product Thinking

Before I ever wrote a PRD, I built a wireless EV-charging prototype using inductive power transfer. It won the branch expo and was published in JETIR. Around the same time, I shipped an autonomous ESP32 robot with GPS tracking and live video. The EV paper was accepted. I don't think I read it after it went up - I was already on to the next thing, which is either a healthy instinct or a bad habit. I've gone back and forth on it.

Engineering projects at the college level reward complexity. The temptation is always to add another feature, another sensor, another mode - because the grading rubric doesn't penalise over-scope. Real product work does. The transferable skill wasn't the hardware. It was learning to defend one working thing against ten interesting ones.

The JETIR submission process changed my writing habits permanently. Peer reviewers are the least sympathetic readers you will ever have. They do not care about your intent. They care about whether your claim is supported. Every 'clearly' I wrote came back circled.

I now assume every PRD reader is a peer reviewer. If a claim isn't backed by a number, a screenshot, or a named user, I flag it before someone else does.

On the EV charger, I had to choose between chasing a higher efficiency rating (harder, longer, deadline at risk) or shipping 85% with clean documentation. I picked 85% and a good paper. It was the first time I traded a technical result for a delivery result, and the discomfort of that choice is what taught me what PM prioritisation actually feels like.

On the robot, I removed the second camera two weeks before the demo because power draw was ruining battery life. Losing the feature made the whole product work. That is the same conversation I have with engineers now, in different words.

Write claims like a peer reviewer will read them. Trade features for reliability without apologising. Respect the constraint you can't argue with - battery, latency, budget - before you optimise the one you can.

Those aren't hardware lessons. They're just product lessons I learned the hard way first.

For a while I treated the hardware background as a resume line. It's more useful as a set of instincts. The instinct that a system will fail at its weakest link, not its strongest, is a PM instinct dressed as an engineering one.

If someone walked in today with a hardware paper and no software portfolio, I'd still put them in a PM interview loop. The transferable skill is not the domain. It's the willingness to ship one thing that actually works.