VP of Product. 7+ years. Ships AI products to millions.
This page answers every question in the LeadSquared application.
With the same obsessive detail I bring to everything I build.
Built with Claude Code. 2,500+ lines of Python. Production-grade.
I'm a VP of Product in Indian financial services, trying to break into AI-native companies globally. The challenge: PM roles at companies like Anthropic, OpenAI, and Cursor aren't posted on job boards. They're buried in Twitter threads, LinkedIn posts, and YC listings. Manual cold outreach doesn't scale. Generic templates get ignored. And I was spending 3-4 hours daily on what should be a systematic pipeline.
I needed a system that could scrape, filter, research, compose personalized emails, generate per-company resumes, send at scale, and alert me the moment someone replied. So I built one.
This isn't a script that sends spam. It's a system that thinks. The tiered composition engine allocates research effort proportionally — Anthropic gets a hand-crafted email with deep company research, while a generic SaaS company gets an auto-composed template. Every email includes a freshly generated, company-specific PDF resume. The triple-checkpoint guardrails ensure I never accidentally email an engineering role. And the moment someone replies, I get an iMessage on my phone with a preview.
The entire system was built in Claude Code — Claude was my pair programmer for every module. I used AI to architect the pipeline, debug edge cases, and compose the tiered prompts. But every product decision — the scoring system, the guardrail patterns, the warm-up schedule — was mine.
7-stage pipeline. Each stage has its own module, its own error handling, its own guardrails.
Apify actors scrape Twitter and LinkedIn for PM hiring posts. Email extraction handles obfuscation patterns ([at], (dot)). YC Work at a Startup gets its own dedicated scraper. 33 PM-focused search keywords, 100+ posts per batch.
43 regex patterns qualify PM/GTM roles. 37 patterns hard-reject engineering, design, sales. Every target passes through guardrails at scrape time, research time, AND send time. Three output buckets: qualified, manual-apply, rejected.
10-point scoring system. Frontier AI labs (Anthropic, OpenAI) score 10. AI-native companies score 8-9 based on LLM/agent/model keyword density. Dev tools score 7. B2B SaaS scores 6. Score determines composition tier and effort allocation.
Tier 1 (score 9-10): Claude agent does deep company research, hand-crafts email with specific portfolio link. Under 150 words. Tier 2 (score 7-8): company-specific hooks from post context. Tier 3 (score 5-6): auto-composed template with domain-aware openers. No agent needed.
reportlab generates a fresh PDF per company. Never cached, never reused. Designation logic: leadership keywords trigger 'VP of Product', else 'Senior Product Manager'. ATS-friendly formatting. Company name in filename.
Gmail App Password auth. 10-second delay between sends. 4-week warm-up schedule: 100/day to 500/day. Message-ID tracking for follow-up threading. Dedup against applied.xlsx before every single send. List-Unsubscribe header for compliance.
IMAP polling checks Gmail inbox against applied.xlsx emails. Reply detected? Instant iMessage alert via macOS osascript with subject, sender, preview. applied.xlsx status updated to 'replied'. Auto follow-ups at Day 5, 12, 20 with proper email threading.
Apify (Twitter/LinkedIn) + YC Scraper + Watchlist (25 dream companies) | v GUARDRAILS #1: 43 qualify patterns, 37 reject patterns |-- qualified (PM + email) --> research queue |-- manual_apply (PM, no email) --> manual_apply.json |-- rejected (wrong role) --> skipped.xlsx | v TIERED SCORING: 10-point AI-trajectory scale |-- Tier 1 (9-10): Anthropic, OpenAI --> deep research + hand-crafted |-- Tier 2 (7-8): Scale AI, Cursor --> company hooks |-- Tier 3 (5-6): Generic PM roles --> auto-template | v GUARDRAILS #2: relevance_score >= 5 filter | v COMPOSE: Claude agents (Tier 1/2) + auto-compose (Tier 3) | v RESUME GEN: reportlab PDF, per-company, designation-aware | v GUARDRAILS #3: final gate before SMTP | v SMTP SEND: warm-up schedule, 10s delay, Message-ID tracking |-- Log to applied.xlsx (THE dedup source) | v IMAP MONITOR: reply detection --> iMessage alert --> status update | v AUTO FOLLOW-UP: Day 5, 12, 20 with email threading
Time saved: 3-4 hours/day of manual outreach reduced to a single command. What used to take a week of manual cold emailing now runs in 20 minutes.
Quality improvement: 5-8% reply rate vs. the 2-3% cold email benchmark. Tier 1 targets (AI labs) get emails that demonstrate genuine research, not spray-and-pray.
Scale: 500+ personalized outreach emails per campaign, each with a unique resume PDF, proper email threading, and follow-up automation.
Zero errors: Triple-checkpoint guardrails mean I've never accidentally emailed an engineering role or sent a duplicate.
Persona: Insurance Verification & Pre-Authorization Team
I spent a full day at a multi-specialty hospital in Mumbai shadowing the pre-authorization team. What I observed was a workflow that hasn't materially changed in 15 years despite every other part of healthcare going digital. Coordinators juggle 4-8 insurance portals, make 20+ phone calls daily, maintain manual Excel trackers, and process 25-40 cases each. The average prior authorization adds 5+ days to a patient's time-to-treatment. 15-30% of requests are denied, often for preventable documentation gaps.
This is the exact kind of problem I've spent my career on: a regulated, high-stakes process drowning in manual work, where AI and automation can dramatically reduce effort, cost, and errors without replacing human judgment.
6 manual steps. Each one a potential failure point.
A physician orders a procedure (MRI, surgery, specialty drug). The order lands as a paper form or EMR notification. The pre-auth coordinator manually identifies that this procedure requires prior authorization based on their memory of payer rules. No automated flagging.
Coordinator logs into 4-8 different insurance portals to check if this specific procedure needs pre-auth for this specific patient's plan. Each payer has different rules, different portals, different login credentials. Average time: 15-25 minutes per case just to determine requirements.
Pull patient history, lab results, imaging reports, physician notes from the EMR. Cross-reference with payer-specific clinical criteria (InterQual, MCG). Often requires chasing physicians for additional documentation or clarification. This step alone takes 30-60 minutes.
Manually enter clinical data into the payer's portal or fax (yes, fax) the documentation. Each payer has a different submission format. Some require phone calls where the coordinator waits on hold for 20-45 minutes. One coordinator handles 25-40 cases per day.
Auth requests sit in limbo for 3-15 business days. Coordinators maintain manual spreadsheets to track status. They call payers repeatedly for updates. No automated status notifications. If documentation is insufficient, the cycle restarts from Step 3. Denial rate: 15-30%.
Once approved or denied, the coordinator manually updates the EMR, notifies the scheduling team, and informs the patient. Denials trigger a separate appeals process that can take weeks. The patient often has no visibility into where their authorization stands.
5 automated stages. Human-in-the-loop where judgment matters. AI everywhere else.
An LLM layer sits on top of the EMR. When a physician places an order, the system automatically identifies whether pre-authorization is required by cross-referencing the procedure code (CPT), the patient's specific insurance plan, and the payer's current rules (ingested via API or periodic scrape). Zero manual lookup. Flags the coordinator only for edge cases.
The system pulls all relevant clinical documentation from the EMR automatically: patient history, labs, imaging, physician notes. An AI model maps this documentation against the payer's specific clinical criteria (InterQual/MCG guidelines), highlights gaps, and pre-fills the submission form. What took 30-60 minutes now takes 2-3 minutes of human review.
A unified submission layer handles all payer portals through API integrations (where available) and RPA bots (for portal-only payers). The system formats documentation to each payer's specific requirements automatically. No more logging into 8 different portals. One click to submit.
Automated polling of payer portals for status updates. ML model predicts approval probability based on historical data (procedure type, payer, clinical documentation quality). Proactive alerts when a case is likely to be denied so the team can strengthen documentation before the decision. Patient gets SMS/portal updates.
When a denial occurs, the system automatically categorizes the denial reason, pulls the specific clinical criteria that weren't met, and drafts an appeal letter with the missing evidence highlighted. Appeals that previously took days of manual work are now generated in minutes with human review.
Effort reduction: Coordinator handles 80-120 cases/day (vs. 25-40 today) because 70% of cases are auto-processed with human review only.
Time-to-treatment: Average pre-auth processing drops from 5+ days to same-day for 60% of cases (auto-approval for clear-cut cases).
Denial rate: Drops from 15-30% to 5-10% because AI pre-checks clinical documentation against payer criteria before submission.
Cost: A 10-person pre-auth team at ~$4K/month each = $480K/year. With automation, the same team handles 3x volume, or the hospital saves $320K/year on a smaller team handling the same volume.
The same data that powers the workflow redesign unlocks intelligence the hospital has never had.
By analyzing approval/denial patterns across payers, procedure types, and clinical documentation quality, hospitals can predict which requests will be denied and proactively strengthen them. A hospital processing 50K auth requests/year could identify that Payer X denies knee MRIs 40% of the time when submitted without conservative treatment documentation, but only 5% when it's included.
Cross-referencing scheduled procedures against authorization status reveals procedures performed without valid authorization (revenue leakage risk) and authorized procedures never scheduled (lost revenue). At average denial write-off rates of $5K-15K per case, even a 5% improvement in catch rate on a 50K case volume = $12.5M-37.5M in recovered revenue.
Time-series analysis of auth request volumes by day, payer, and procedure type enables predictive staffing. Instead of fixed teams, hospitals can flex coordinators to peak-demand periods. Data shows most auth requests cluster Monday-Wednesday. A 10-person team could operate at 7 on Thursdays/Fridays without SLA degradation.
By scoring the completeness and relevance of clinical documentation before submission (using the same criteria payers use), the system can identify physicians or departments that consistently produce weak documentation. Targeted training for the bottom 20% of documentation quality scores could reduce denial rates by 8-12%.
Combining auth processing times with patient scheduling data reveals the true cost of authorization delays on patient care. If the average pre-auth adds 5.2 days to time-to-treatment, and 12% of patients cancel procedures during the wait, that's quantifiable harm and lost revenue. This data becomes leverage for payer contract negotiations.
n8n workflow that reads a JD, evaluates resumes, scores relevance, and maintains a live Google Sheet.
The workflow monitors a Google Drive folder for new resume uploads. When a new PDF appears, it triggers a pipeline that extracts text from the resume, reads the job description from a separate folder, sends both to Claude for structured evaluation, and writes the results to a Google Sheet with candidate name, contact details, relevance score (0-100), and detailed reasoning.
6 nodes. Fully automated. Handles edge cases.
Monitors the Resumes folder for new PDF uploads. Fires on file creation. Passes the file ID and metadata downstream. Polling interval configurable (default: every 2 minutes for near-real-time processing).
Downloads the PDF from Google Drive and extracts text content. Handles multi-page resumes, different PDF encodings, and scanned documents (with OCR fallback). Passes raw text + file reference to the next node.
Reads the latest JD PDF from the Job Description folder. Caches the extracted JD text to avoid re-processing on every resume. Only re-fetches when the JD file is modified. This ensures consistency across all resume evaluations.
Sends both resume text and JD to Claude with a structured prompt. Returns: candidate name, email, mobile, relevance score (0-100), and detailed reasoning covering skills match, experience alignment, education fit, and specific gaps. Handles extraction failures gracefully.
Validates Claude's output structure. Handles missing contact info (marks as 'Not Found'). Normalizes scores to 0-100 range. Flags resumes that couldn't be parsed (corrupt PDFs, image-only scans) for manual review. Deduplicates by candidate email.
Appends results to the output Google Sheet with columns: Candidate Name, Mobile, Email, Resume File Link, Relevance Score, Reasoning, Evaluated At. Auto-sorts by relevance score descending. Color-codes rows: green (80+), yellow (50-79), red (below 50).
Multi-criteria scoring: Instead of a single relevance number, the prompt asks Claude to score across 5 dimensions (skills match, experience relevance, education fit, cultural signals, red flags) and compute a weighted composite. The reasoning explains each dimension.
Deduplication: If the same candidate uploads an updated resume, the workflow updates the existing row rather than creating a duplicate. Matched by email address.
Batch processing: If multiple resumes are uploaded simultaneously, the workflow processes them in parallel (up to 5 concurrent evaluations) to avoid bottlenecks.
Hiring insight: A summary node runs daily, analyzing the distribution of scores and flagging when top candidates cluster (signaling a strong applicant pool) or when scores are uniformly low (signaling a JD mismatch).
While applying for this role, I didn't write a cover letter. I built a production-grade AI system that automated my entire job search — scraping, filtering, researching, composing, sending, and monitoring replies across 500+ targets. The system you read about in Question 1 isn't a hypothetical. It's running right now. It sent me an iMessage alert this morning.
Most PM candidates talk about automation. I built one that does the work of a 3-person outreach team, with better personalization, zero errors, and a reply rate 2-3x above industry benchmarks. That's not a trait or an intention — it's a system you can inspect on GitHub, and results you can verify.
At Motilal Oswal, I'm VP of Product managing 5 PMs, shipping AI products to 10M+ users in one of India's most regulated industries. I've built recommendation engines, customer data platforms, trading apps, and a 17-module HRMS. But what makes me different isn't the resume — it's that when I see a broken process, I don't just spec the solution. I build it. Tonight. In Claude Code.
Job Autopilot isn't a prototype. It's 2,500 lines of Python processing 500+ targets with triple-checkpoint guardrails. I build the thing, not just the spec for the thing.
AI recommendation engines, cross-border trading platforms, embedded insurance infra. Products that move real money for real people. The stakes weren't hypothetical.
I didn't build an email sender. I built a 7-stage pipeline with scoring, tiering, guardrails, and monitoring. Every system I touch gets this treatment.
Claude Code is my daily tool. I've built agentic workflows, RAG pipelines for financial regulations, and published a 52-use-case playbook for AI agents in financial services.