Resume Teardown #66: CS Grad PM Transition, 72% Score, Two Surgical Fixes Needed
This is part of our Resume Teardown series where we score real PM resumes (anonymized) and break down what the evaluation found.
TL;DR: A CS graduate transitioning to product management with 1.5 years of product-adjacent experience scored 72%. For a transition candidate without a PM title, this is a strong score. Real execution signals: shipped a CRM automation that cut turnaround from 7 days to 3 hours, reduced post-launch support tickets 30% at an enterprise software company, and built AI pipelines end-to-end. Two specific fixes would make this competitive for APM and technical PM roles.
The Resume
Background: Technical Executive at a data and automation startup (Nov 2024-Mar 2026). Previously Product Analyst Intern at an enterprise publishing software company. B.E. in Computer Science from an engineering college. 1.5 years of product-adjacent work experience. Multiple self-driven product projects including an AI recommendation engine, a community platform, and a compliance workflow prototype.
What looked good on the surface:
- Real execution in current role: shipped n8n automation with Zoho CRM integration end-to-end
- Internship at a recognizable enterprise software company with PM-adjacent deliverables
- Technical depth supported by work, not just listed: REST APIs, SQL, FastAPI, Postman, n8n, LLM integrations
- PM craft visible in internship: requirements writing, user stories, acceptance criteria, UAT
- Side projects demonstrate initiative: AI pipeline with FastAPI and Gemini, consumer platform, usability research
Score: 72%
Why 72% Is a Good Score for This Profile
Before getting to the gaps, it is worth naming what the score means in context. 72% for a transition candidate without a PM title is above average for this stage. The evaluation calibrates against others at the same seniority level, and most APM/transition resumes in the 60s or low 70s earn it because they have certifications and coursework but no shipped work.
This resume has shipped work. The Zoho CRM automation went live and measurably improved a business process. The Quark internship produced requirements that reduced real support tickets. The GST Saathi prototype was tested with real users and iterated toward a measurable quality improvement. This is not a candidate who needs more experience. This is a candidate who needs to reframe the experience they have.
The hiring manager verdict confirms this: "I would be interested but conditional rather than a clear yes." The gap between conditional and clear yes is specific and closable.
The Strongest Signal: The CRM Automation Bullet
"Built and shipped an n8n automation pipeline integrated with Zoho CRM via REST API, worked directly with JSON payloads, API authentication, and database writes to eliminate a manual lead capture process, reducing turnaround from 7 days to under 3 hours."
This is the best bullet on the resume. It has a problem (manual lead capture process), a technical decision (n8n + Zoho CRM via REST API), and a before/after outcome (7 days to under 3 hours). A recruiter reading this understands that this person shipped something that worked.
But it is missing one thing that would make it a PM bullet instead of a builder bullet: the product decision context. Why was this automation prioritized? Who were the internal users? What did you learn about the problem before designing the solution? Was there a tradeoff you made in the approach?
Before: "Built and shipped an n8n automation pipeline integrated with Zoho CRM via REST API... reducing turnaround from 7 days to under 3 hours."
After: "Identified that the sales team was manually re-entering leads from 3 sources into Zoho CRM, causing 7-day lags in follow-up. Defined the requirements, built and shipped an n8n automation pipeline integrated via REST API, and validated with the sales team before handoff. Reduced turnaround from 7 days to under 3 hours."
Same work. Same outcome. But now the bullet shows: problem identification, requirements definition, user validation, and result. That is the PM layer the hiring manager is looking for when they say "I still have to infer your product decision-making."
The Tool-Heavy Bullet: The Easiest Fix
"Used Claude, Gemini, Cursor, and Postman daily to prototype ideas, test API endpoints, and validate integrations before handing to engineering."
This bullet lists tools and activities. It does not answer: what product question did you validate? What integration risk did you identify and de-risk? What decision did the prototype enable? What would have gone differently if you had not run this validation?
Before: "Used Claude, Gemini, Cursor, and Postman daily to prototype ideas, test API endpoints, and validate integrations before handing to engineering."
After: "Prototyped API integrations using Postman and LLMs before engineering pickup, identifying 3 edge cases in authentication flow that would have required rework after handoff. Reduced integration-related engineering cycles by catching requirements gaps at the prototyping stage."
Now the bullet shows: what you were doing (pre-engineering validation), what you found (edge cases), and what it prevented (rework cycles). The tools are still there as context. The product judgment is now visible.
The Quark Internship: Already Strong, One Addition
The internship bullets are the closest thing on this resume to traditional PM work:
"Wrote clear functional requirements, user stories, and acceptance criteria for enterprise B2B features — reducing post-launch support tickets by 30% through clearer engineering handoffs."
30% support ticket reduction tied directly to clearer requirements is a real outcome and a strong PM transition signal. This bullet is already working. The one addition that would strengthen it: what was the feature area? Even a generic descriptor like "enterprise content management workflows" or "publishing API integrations" gives a recruiter context about the problem space.
"Identified 18 pre-launch defects across 6 UAT cycles by looking at products from both user and engineering perspectives."
Good. The "both user and engineering perspectives" framing explicitly names the PM skill. The bullet holds up.
The Scout Project: Abstract Outcome Language
"Built Scout: an AI recommendation engine, end to end: identified the problem, scored solutions, shipped a working MVP, and built a causal metrics framework."
"Causal metrics framework" sounds rigorous but is too abstract for a recruiter scan. What problem was Scout solving? What does the recommendation engine recommend, for whom, in what context? What was the primary success metric you chose, and why?
The Blinkit context (it is framed as a Blinkit growth case study) is helpful but gets lost. Make it explicit: "Built Scout, an AI-powered dark store recommendation engine for a Blinkit-style quick commerce scenario: identified the inventory gap problem through data analysis, defined success as order fulfillment rate improvement, and shipped a working MVP with FastAPI and Gemini that surfaced real-time inventory substitution recommendations."
Now the project has: domain (quick commerce), problem (inventory gaps), metric (fulfillment rate), and technical proof (FastAPI + Gemini). A recruiter can evaluate it.
The AI Quality Gap: One Bullet Would Close It
Across all three AI-related bullets and projects, there is no mention of how AI output quality was evaluated or what happened when the model produced bad responses.
For a candidate targeting AI PM and technical PM roles, this is a specific gap. Did the Gemini pipeline ever return irrelevant recommendations? How did you handle it? What was the fallback if the Gmail API integration failed mid-pipeline? In the GST Saathi prototype, what happened when AI validation produced false positives?
One bullet showing this thinking would complete the AI PM picture:
"In the production pipeline, Gemini occasionally returned malformed JSON for edge-case inputs. Added a validation layer with structured output enforcement and a fallback to a rule-based response for inputs that failed parsing, preventing silent failures in downstream automation."
Whether or not that specific scenario occurred is less important than the structure: identified a failure mode, designed a handling strategy, prevented downstream impact. Any version of this pattern from the actual project work would work.
The Summary: Good Structure, Needs a Hook
"CS graduate with 1.5 years of experience in technical and operational roles, working closely with engineers, writing requirements, and shipping AI-powered automations end to end."
The summary is honest and clear. The problem is it leads with "CS graduate" and "1.5 years" — both of which anchor the reader's calibration at junior/entry level before the actual evidence changes the impression.
Transition candidates should lead with their strongest signal, not their title or tenure.
Reframe:
Before: "CS graduate with 1.5 years of experience in technical and operational roles, working closely with engineers, writing requirements, and shipping AI-powered automations end to end."
After: "Technical PM transition candidate with shipped AI automations and enterprise product-adjacent experience at an enterprise software company. Cut a 7-day manual process to under 3 hours through CRM automation. Strong in REST APIs, LLM integrations, requirements writing, and pre-engineering prototyping."
Now the summary leads with: type of role targeted (technical PM transition), proof (shipped automations), recognizable context (enterprise software company), signature outcome (7 days to 3 hours), and skills that differentiate (REST APIs, LLMs, requirements, prototyping).
The "Technical Executive" Title Problem
The current role title "Technical Executive" means nothing to a PM recruiter. It reads as operations, IT support, or business analyst work depending on the reader's background. The title is followed by bullets that show real product-adjacent work — but many recruiters will not read that far.
The fix is a scope clarifier, not a title change. Add one line under the company name:
"Owned workflow automation, API integrations, and pre-engineering validation in a product-adjacent role supporting the company's data and CRM operations."
This gives a recruiter the context to read the bullets correctly before they start.
Dimension Scores
Skills: 78% — The strongest dimension. Technical stack is well-evidenced: REST APIs, SQL, FastAPI, n8n, Postman, LLM integrations. PM craft is visible in requirements writing, user stories, acceptance criteria, and UAT from the internship. The gaps are tool-heavy bullets without product judgment, and AI work without quality evaluation methodology.
Experience & Background: 74% — Coherent transition arc: enterprise software internship, product-adjacent full-time role, and self-driven product projects. The Quark brand provides credibility. The gap is no PM title yet, and the current role title undersells the scope. The internship and projects together make a stronger case than either alone.
Leadership & Impact: 70% — Real ownership is visible at the scale expected for this stage. The CRM automation outcome and the Quark defect catch rate are the anchors. Most bullets stop at delivery rather than showing the decision that preceded it. One or two bullets reframed to show "what I chose and why" would close this gap.
Domain Expertise: 58% — The weakest dimension, and expected at this stage. Enterprise software and B2B workflows are the clearest lane, but the projects span quick commerce, compliance, and community platforms without a primary domain thread. For APM applications, domain depth matters less than PM craft. For technical PM roles, one clear domain specialization would help.
ATS Readiness: 88%
One of the stronger ATS scores in the series. Clean section headers, standard acronyms, logical top-to-bottom flow, and PM keywords distributed across both summary and experience bullets. The main gaps: roadmap, discovery, go-to-market, retention, adoption, and experimentation are absent from recent bullets. Minor formatting issues including a hyphenated line break in "require-ments" in the summary reduce polish slightly but do not affect parsing.
Key Takeaways
1. 72% without a PM title means the builder signals are working. Shipped work beats coursework every time. The CRM automation and Quark internship outcomes are the reason this resume would get callbacks. Protect and strengthen them.
2. Add the problem identification layer to your strongest bullets. "Built and shipped X, achieving Y" is an engineer's bullet. "Identified Z problem, designed and shipped X, achieving Y" is a PM's bullet. The difference is one sentence. Add it to the CRM automation and Zoho bullets first.
3. Your tool list needs a payoff line. Listing Claude, Gemini, Cursor, and Postman is not PM evidence. What question did you answer using those tools? What would have gone differently without that prototyping step? Answer that question in the bullet.
4. One AI quality management example would separate you from most APM candidates. Most technical PM transition resumes show AI building. Almost none show AI quality thinking: failure modes, evaluation criteria, fallback design. One concrete example from your actual project work would be a differentiator in AI-adjacent PM screening.
5. Lead the summary with your strongest signal, not your tenure. "CS graduate with 1.5 years" anchors the recruiter at entry-level before the bullets change the impression. Lead with what you have shipped and where you have worked, then the tenure becomes context rather than the headline.
The Pattern
This resume represents the "technically strong transition candidate, product judgment not yet visible" archetype. The candidate has done real work: shipped automations, written requirements that reduced defects, iterated a prototype with real users. The technical fluency is genuine.
The gap is not experience. It is framing. Every execution bullet has a missing layer: the problem identified before building, the decision made about approach, the failure case handled in the AI pipeline. Adding that layer to three or four existing bullets — without adding new experience — is the entire fix.
At 72%, this resume already clears the threshold for APM and technical PM callbacks at companies that value builder backgrounds. The targeted edits would make it difficult to pass on.
Score your own resume to see how your PM resume performs across all four dimensions.