Breaking into remote PM roles from Nepal — a realistic roadmap
The career advice for breaking into product management usually assumes you’re in San Francisco, went to a good school, and have a friend who can refer you into a role. None of that applies to me.
Here’s the version of this that’s actually true for someone coming from a technical background in Nepal.
Why engineering is actually a good starting point
Industrial engineering is about systems: inputs, outputs, constraints, and waste. When I started reading PM literature seriously, I kept recognizing the same patterns — just with different vocabulary.
Bottleneck analysis is user journey analysis. Process flow diagrams are user flows. FMEA (failure mode and effects analysis) is pre-mortem thinking. The IE toolkit maps onto product work more directly than most people realize.
The gap isn’t frameworks. The gap is customer empathy, product intuition built from using many products critically, and the ability to communicate technical trade-offs to non-technical stakeholders.
What actually matters for the transition
I’ve been wrong about this before, so I’ll be specific.
Writing is the most important skill. PMs communicate in writing — PRDs, spec docs, decision memos, Slack threads that become policy. If you can’t write clearly, you can’t do the job. I started writing publicly partly to get reps in.
SQL is not optional. Not because you’ll be doing data science, but because you need to be able to answer your own questions without waiting for a data team. Every senior PM I’ve read or listened to says some version of this.
Portfolio work beats credentials. An MBA signals career intent. A portfolio of actual product work — PRDs for real problems, analyses of products you use, case studies of decisions you’d make differently — shows capability. The second is harder to fake.
Remote-first companies are the path. The Nepal timezone is not ideal for synchronous collaboration with US teams. But it’s fine for async-heavy companies — which correlates with better documentation, clearer processes, and healthier engineering culture anyway. Optimize for those companies.
The honest timeline
I’m currently in month three of a six-month structured plan. The months look roughly like this:
- Months 1–2: Foundation — user research methods, PRD writing, PM frameworks, SQL refresher
- Months 3–4: Application — write real PRDs for products I use, start publishing analysis publicly
- Months 5–6: Job search prep — portfolio review, mock interviews, applications to remote-first companies
The tracker I built (PM Roadmap Tracker) is how I’m keeping myself honest about the plan.
What I’m not doing
I’m not doing a product management bootcamp. The ones I’ve seen teach process without building judgment. They’re optimized for getting you a certificate, not getting you ready for the job.
I’m not waiting until I feel “ready” to start applying. You never feel ready. You apply when you have enough to show, and you learn the rest on the job.
The advantage of the unusual path
Here’s something I’ve started believing: the path through industrial engineering and data analysis into PM is actually useful, not just tolerable.
Most PM candidates come through the same pipeline — consulting, MBA, big tech APM program. They have similar mental models, similar frameworks, similar blind spots.
A PM who has spent time optimizing industrial processes thinks differently about throughput, constraints, and waste. A PM who does data analysis thinks differently about measurement and causality. That’s differentiation you can’t fake and can’t get from a bootcamp.
The question is whether you can communicate it as a coherent narrative. I’m working on that too.