I didn't set out to become a product manager. I set out to build software that worked — clean migrations, sane APIs, queues that didn't fall over at 2 a.m. Five years and a lot of Laravel later, I realized the hardest problems were never the technical ones. They were the questions no endpoint could answer: should we build this at all, and for whom?
Engineering taught me to respect constraints
A backend engineer lives inside constraints — the shape of the data, the cost of a query, the blast radius of a migration on a live table. That instinct turned out to be the most transferable skill I had. When I sit in a roadmap discussion now, I can hear the difference between a feature that's a week of work and one that quietly rewrites half the system. Estimates stop being guesses and start being conversations.
Product taught me to respect the user more than the architecture
Engineering rewards elegance. Product rewards outcomes, and users don't care how elegant the solution is if it doesn't fit their day. Moving into product management forced me to hold two truths at once: the system has to stay healthy and the person on the other side has to succeed in the first thirty seconds. At Sepehr IT, building storefront and marketing platforms, that tension is the whole job.
You can't prioritize what you don't understand — and you can't understand a product only from the outside.
What I'd tell my past self
If you're an engineer wondering whether the move is worth it: your technical depth is not baggage, it's leverage. It lets you challenge a bad estimate, spot the risky dependency, and earn the trust of the people who'll actually build the thing. The code you wrote wasn't a detour from product — it was the apprenticeship.
This is the first post on a site I built end to end — Next.js on the front, Laravel on the back, bilingual by design. More to come on product, engineering, and the space where they meet.