I Went From Writing Code to Running Product. No MBA, No Shortcuts.
My unconventional journey from backend developer to Director of Product Management. The pivots nobody talks about, the mistakes that shaped me, and what I wish I knew at 23. A blueprint for aspiring PMs - especially those coming from tech.
⏱ 22 min read2016, age 22: Fresh engineering grad. Backend developer at a fintech company. Writing Java code I barely understood. Terrified of meetings.
2026, age 32: Director of Product Management at India's leading fintech. Leading products used by millions of users. Managing teams of 30+ PMs and engineers.
This is the messy, non-linear journey that career advice blogs never show you.
From backend developer to Product Director. 7 companies. 3 failed startups. 2 acquisitions. Countless mistakes. Zero regrets.
When I started coding at age 22, I had ZERO interest in product management. I didn't even know it existed. I wanted to be a "rockstar developer" (cringe, I know).
Today, aspiring PMs ask me: "How do I break into product management?"
I tell them the uncomfortable truth: There is no standard path. The people who succeed in PM aren't the ones who follow a playbook - they're the ones who build skills nobody asked them to build.
"Product management isn't a destination. It's a mindset you develop by accident while trying to solve problems bigger than your job description."
Part 1: The Journey (2016-2026)
Here's my actual path - not the LinkedIn version, the real one with failures, pivots, and things I'm not particularly proud of.
Learning to code Multi-role
Startup chaos PM at Scale
Structured growth Director
Leading teams
First job out of college. Global fintech company. Sounds impressive. Reality: I was a cog in a massive wheel, writing backend services I didn't understand.
Worked at a tech services company by day. Consulted for a content startup by night. Wore multiple hats: backend dev, product, community, growth - whatever needed doing.
First official PM role. Joined at "idea stage." Built the MVP. Helped implement unique matching features. Learned what it means to build something from absolute zero.
B2B SaaS. Completely different from consumer. Learned enterprise sales, complex stakeholder management, and why "AI-powered" doesn't mean customers care.
First VC-backed startup. Fintech = regulation + scale + trust issues. Launched UPI payments. Dealt with RBI compliance. Watched competitors get shut down overnight. This is where I learned product management at scale.
Joined India's leading fintech unicorn. No longer a founding team member - now working at scale. Managing products with millions of users. First time leading other PMs.
Leading consumer product charter. Managing 30+ person product and engineering org. Setting strategy, not just executing it. Working directly with founders and CXOs on company direction.
Want to Break Into Product Management?
I help engineers, analysts, and career-switchers land their first PM role - no MBA required.
Get Free Guidance →Part 2: The Technical Background Advantage (And Why It's Not What You Think)
People romanticize the "developer to PM" transition. "Engineers make the best PMs!" they say.
That's both true and misleading.
Yes, my technical background helped. But not in the way people think.
Non-technical PMs struggle with this. Engineers dismiss them as "business people who don't understand tech."
This speeds up product development by 30-40%. I don't bottleneck on technical questions.
This prevents wasted engineering effort on poorly-scoped features.
I don't just report bugs. I help solve them. This earns massive respect.
❌ But Here's Where Technical Background HURTS You
1. You over-engineer solutions. Early in my PM career, I'd design technically elegant solutions that users didn't care about. I was solving for "clean architecture," not user problems.
2. You focus on "how" instead of "why." I'd spend 2 hours debating implementation details instead of validating if the feature was even needed.
3. You trust data over user empathy. Engineers love metrics. But the best insights come from watching a confused user struggle with your product for 5 minutes.
4. You undervalue design and UX. I spent my first 2 years thinking UX was "just making things pretty." Wrong. UX IS the product.
💡 The Moment That Changed Everything
At the dating startup, we spent 3 weeks building a "smart matching algorithm" with ML models. Technically impressive. Users hated it. Why? It was slow and unpredictable.
We replaced it with a simple rule-based system. Built in 2 days. Users loved it. It was fast and they understood how it worked.
Lesson: Stop optimizing for technical elegance. Start optimizing for user outcomes. The best solution is the simplest one that solves the problem.
Part 3: The Skills That Actually Matter (In Order of Importance)
Here's what separates good PMs from great ones. Spoiler: it's not what job descriptions say.
Focus: Ship features. Build judgment. Learn what good looks like. Don't worry about strategy yet - you need reps.
Focus: Say no to most things. Build strategic thinking. Learn to see 3-6 months ahead. This is where most PMs plateau.
Focus: Your job is multiplying others, not executing yourself. If you're still writing PRDs at this level, you're doing it wrong.
🎯 The One Skill That Predicts PM Success
It's not technical skills. It's not communication. It's not even intelligence.
It's bias for action.
The best PMs I know are relentlessly biased toward DOING. They ship imperfect things. They run experiments with 60% confidence. They make decisions with incomplete information.
The worst PMs overanalyze, seek consensus, and wait for perfect information. By the time they're ready to ship, the market has moved.
Is Your PM Resume Getting You Interviews?
Most PM resumes get rejected in under 10 seconds. Let me help you fix that.
Get a Free Resume Review →Part 4: Breaking Into PM (The Actual Playbook)
Okay, enough about my journey. Here's what you actually came here for: How do I get my first PM job?
Step 1: Start Acting Like a PM (While You're Still a Developer)
What to do:
• Volunteer for user research sessions
• Question WHY you're building features, not just HOW
• Write technical specs with user impact in mind
• Present your work in terms of business outcomes, not code quality
• Attend product meetings even when not required
Real example: As a backend dev, I started asking "Why are we building this API?" in sprint planning. Initially annoying. Eventually valuable. Led to my first product discussions.
Step 2: Build a Portfolio of PM Work (Even Without the Title)
What to do:
• Side projects where you own product decisions (not just code)
• Write case studies analyzing products you use
• Run experiments on your own projects and share learnings
• Create a blog/social media documenting your product thinking
Why this matters: When I interviewed for my first PM role, I had ZERO PM experience on paper. But I had built side projects, analyzed competitors, and could articulate product thinking. That got me the job.
Step 3: Target Startups, Not Big Tech (Initially)
The reality: Big tech companies won't hire you as a PM with zero PM experience. Startups will.
Why startups work:
• They value hustle over credentials
• They need people who can wear multiple hats
• Technical background is a huge plus
• You'll get 10x more responsibility, 10x faster
My path: Dating startup (idea stage) → B2B SaaS (pre-revenue) → VC-backed fintech (seed stage) → Major fintech (scale-up). Each jump was possible because of the last.
Step 4: Position Yourself as "Technical PM"
Early in your career, this is your unfair advantage.
How to position:
• "I can talk to engineers AND customers"
• "I understand technical feasibility AND user needs"
• "I can evaluate build vs buy decisions independently"
This positioning got me interviews at fintech companies where technical depth was mandatory.
Step 5: Get Mentored by PMs (Even If You Don't Know Any)
How I did this:
• Cold messages to PMs at companies I admired (10% response rate)
• Asked for 15 minutes, not "mentorship" (lower commitment)
• Showed up prepared with specific questions
• Followed up with what I implemented based on their advice
Result: Built a network of PM mentors who vouched for me when I applied to roles.
Part 5: The Career Ladder (What Each Level Actually Means)
PM titles are confusing. Here's what they actually mean - not the job description version, the reality version.
What you do: Execute on someone else's roadmap
Success metric: Ship on time, good quality
Reality check: You're learning. You don't set strategy. You implement it. This is OK - everyone starts here.
What you do: Set product strategy, own outcomes
Success metric: Business impact (revenue, retention, growth)
Reality check: You're expected to have opinions on what to build and why. If you're still just executing, you're not really a PM yet.
What you do: Set strategy across products, influence roadmap
Success metric: Org-level impact, team growth
Reality check: You're mentoring junior PMs. You're setting 6-12 month strategy. Founders/VPs ask your opinion on company direction.
What you do: Build teams, shape culture, set company strategy
Success metric: Team success, business outcomes, talent development
Reality check: 80% of your time is people/strategy, 20% is product. If you still want to write PRDs daily, this role isn't for you.
Typical time from first PM role to Director/VP at top companies. Faster at startups (5-7 years), slower at big tech (10-15 years).
I did it in 8 years because I optimized for learning, not stability.
PM Interview Coming Up?
Practice with someone who has interviewed 100+ candidates. Get real feedback, not generic tips.
Book a Mock Interview →Part 6: The Mistakes I Made (So You Don't Have To)
❌ Mistake #1: Chasing Titles Instead of Learning
At 26, I turned down a "Product Manager" role at a stable company to be an "Associate PM" at a startup.
Everyone said I was crazy. "You're going BACKWARDS in title!"
Why it was right: The startup role gave me 10x more responsibility and learning. Titles mean nothing early in your career. Learning velocity means everything.
❌ Mistake #2: Thinking PM Is a Promotion from Engineering
I thought PM was "the next level" after being a developer. Like getting promoted.
Wrong. PM is a completely different career. Different skills. Different mindset. Different success metrics.
The truth: Some developers make terrible PMs. Some great PMs can't code at all. It's not a linear progression - it's a career change.
❌ Mistake #3: Not Building a Network Early
For the first 4 years of my career, I didn't network. I thought "good work speaks for itself."
Reality: Good work gets you noticed in your company. Networks get you opportunities outside it.
What I should have done: Started writing/sharing learnings publicly at 23, not 28. Built relationships with other PMs early. Attended PM meetups and conferences.
The Uncomfortable Truth About PM Careers
After 10 years and climbing from backend developer to Director, here's what I know for certain:
"The PM career ladder isn't a ladder. It's a jungle gym. You climb sideways, jump across, sometimes go down to go up. The people who win are the ones who optimize for learning, not for their resume."
The survivors understand this. They take pay cuts to join better teams. They switch from PM to growth to product again. They move from B2C to B2B to fintech, collecting skills.
While others optimize their resume, they optimize their judgment. While others chase senior titles at average companies, they take IC roles at exceptional ones.
🔑 Key Takeaways
- There is no standard path to PM. The best PMs build skills nobody asked them to build while doing their current job.
- Technical background gives you credibility with engineers - but you must avoid over-engineering and learn to prioritize user outcomes over technical elegance.
- Start acting like a PM before you have the title. Ask "why" in every meeting. Write specs with user impact. Attend product discussions.
- Target startups for your first PM role, not big tech. Startups value hustle over credentials and give 10x more responsibility.
- The one skill that predicts PM success: bias for action. Ship imperfect things. Make decisions with 60% confidence. Don't overanalyze.
- Junior PM (0-2 years): Learn to ship. Mid PM (2-5 years): Learn to prioritize. Senior/Director (5+ years): Learn to multiply others.
- Optimize for learning, not titles. Better to be an APM at a great company than a PM at a mediocre one.
- 7-10 years from first PM role to Director is typical. Faster at startups (5-7), slower at big tech (10-15).
- PM isn't a promotion from engineering - it's a completely different career requiring different skills and mindset.
- Build your network early. Good work gets you noticed internally. Networks get you opportunities externally.
📚 Building Your PM Career?
I'm writing a series on the real, messy journey of climbing the PM ladder - career pivots, skill building, and lessons from 10 years in product.
Connect with me on LinkedIn for weekly insights on product careers, breaking into PM, and navigating the chaos of startup product management.