Resume Teardown #47: Undergrad Builder with a Live Product but Zero PM Language
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 B.Tech undergraduate with a billing app used daily by a retail store (50+ transactions/day) scored 58%. The resume has something most student applicants lack: a real product with a real user doing real work with it every day. But the entire resume reads as a software engineer's project portfolio. No summary, no PM language, no evidence of user research or prioritization. The PM signal is buried inside engineering framing.
The Resume
Background: B.Tech in Information Technology at a top engineering college (2023-2027). No internships. Four technical projects: a desktop billing app for a live retail store, a typing game, an ML credit scoring model, and an ongoing cross-platform file storage system. Positions of responsibility in college media and tech events.
What looked good on the surface:
- A live product with measurable daily usage (50+ transactions/day at a real store)
- Evidence of iterating based on real user feedback ("improving UX over multiple feedback cycles")
- Strong technical range across desktop, mobile, ML, and systems
- Clean project execution with linked demos
Score: 58%
The Standout: You Already Did Product Discovery (But Did Not Name It)
Most student resumes targeting PM have case studies, hypothetical roadmaps, or academic projects that never touched a real user. This resume has something rarer:
"Built a desktop billing app in Electron, used daily by a retail store (50+ transactions/day) with real-time cart updates, PDF invoice generation, and tax calculation"
"Collaborated with store owner, improving UX over multiple feedback cycles"
Read those two bullets together. You built a product. A real person uses it every day for their livelihood. You gathered feedback from that person. You iterated based on what they told you. You shipped improvements.
That is user research. That is product iteration. That is discovery and delivery.
But the resume does not say any of those words. A PM recruiter reads "built a desktop billing app" and "collaborated with store owner" and files you under software engineering. The same work, named differently, changes everything:
Before: "Collaborated with store owner, improving UX over multiple feedback cycles"
After: "Conducted ongoing user research with the store owner (primary user). Identified pain points in billing speed and invoice clarity through weekly feedback sessions. Prioritized fixes by frequency of complaint and shipped iterative improvements over 3 months."
Same work. PM language. Now a recruiter can see: user research, pain point identification, prioritization logic, iterative delivery.
The Core Problem: An Engineer's Resume Applying to PM
Every project bullet on this resume answers the question "what did I build?" None answers "what problem did I solve, for whom, and what changed?"
| Current framing | PM framing |
|---|---|
| Built X using Y technology | Identified user problem → chose approach → shipped → measured |
| Implemented features A, B, C | Prioritized features based on user need → shipped MVP → iterated |
| Developed backend and frontend | Defined requirements → built solution → tested with users |
This is not a criticism of the work. The work is genuinely strong for an undergraduate. The problem is entirely one of language. When every bullet leads with the technology stack rather than the user problem, recruiters categorize you as an engineer, not a PM.
The Missing Summary: 15 Seconds to Redirect Perception
There is no summary section. For a student targeting PM with zero PM titles or internships, this is the single highest-impact addition.
Without a summary, here is what happens: a recruiter sees "B.Tech Information Technology," scans down to Projects, reads "Electron.js, React.js, SQLite" and "C++, Raylib" and "Python, XGBoost" and closes the tab. They never consider you for PM.
What the summary needs to do:
- State your target: PM/APM roles
- Name what makes you different: you ship products that real people use daily
- Include one proof point with a number
Example: "Engineering undergraduate targeting APM roles. Built a billing product used daily by a retail store (50+ transactions/day), iterated through user feedback, and shipped improvements over 3 months. Looking to apply the same user-focused, ship-and-iterate approach in a product management role."
Three sentences. Now the recruiter reads the rest of your resume through a PM lens.
The Credit Scoring Project: ML Without a User Story
"Built a credit score prediction system using XGBoost to regress credit score based on financial behavior"
This reads as a machine learning homework exercise. A recruiter learns: you can build ML models. They do not learn: you understand users, problems, or product decisions.
The fix is not to remove the project. It is to add the product frame:
Before: "Built a credit score prediction system using XGBoost to regress credit score based on financial behavior"
After: "Built a credit scoring tool that helps users understand what drives their score. Chose XGBoost for accuracy (RMSE: X), then added SHAP-based explanations so users see which financial behaviors to change. Frontend displays personalized recommendations."
Now the bullet shows: user need (understand their score), product decision (chose explainability over black-box accuracy), and user value (personalized recommendations). The ML is the implementation detail, not the headline.
The Gaming Project: Fun but Zero PM Signal
The typing game (Astrotype) is a well-executed engineering project. Trie data structures, skew heaps, game loop architecture. For a software engineering application, this is strong.
For a PM application, it takes up space that could show product thinking. You have two options:
Option A: Reframe it as game design. What user behavior were you designing for? Why these mechanics (typing to destroy asteroids)? Did anyone playtest it? What did you change based on feedback? If you made deliberate design choices about difficulty progression, visual feedback, and engagement loops, say so.
Option B: Replace it. If you have any other project where you talked to users, defined requirements, or made scope trade-offs, that project is more valuable for a PM application than a technically impressive game with no user story.
Dimension Scores
Skills & Tools: 61%
Technical stack is strong and demonstrated through projects (not just listed). But PM craft is absent: no evidence of user research, requirements definition, prioritization, metrics tracking, or experimentation. The "Soft Skills" section listing "Problem Solving, Leadership, Iterative Development" cannot substitute for demonstrated PM activities.
Leadership & Impact: 60%
Builder ownership is clear. The retail billing app with daily usage is genuine product leadership for an undergraduate. But bullets describe what was built, not what changed. No before/after outcomes, no decision rationale, no success metrics.
Experience & Background: 52%
Zero internships. Zero industry exposure. Zero PM-adjacent roles. For APM hiring, this is a significant gap. The projects partially compensate (especially the live billing app), but most APM pipelines require at least one internship on the resume.
Domain Expertise: 50%
Projects span retail software, gaming, fintech (credit scoring), and cloud storage. Breadth is fine for a student, but no vertical has enough depth to position you for domain-specific roles. Pick one to emphasize.
ATS Readiness: 63%
Multiple issues: no Summary section (missing header ATS looks for), no Experience/Work Experience section, PM keywords largely absent from project bullets. The resume would pass a formatting check but fail keyword matching for any PM role because the vocabulary is entirely engineering-focused.
Key Takeaways
1. A live product with a real user is worth more than 5 case studies. Most students applying to PM have hypothetical projects. You have a product someone depends on daily. This is rare and valuable. Frame it that way.
2. PM language is a choice, not a skill gap. You already did user research (feedback sessions with the store owner). You already iterated based on data. You already made prioritization choices (what to fix first). The gap is not in your work. It is in your words.
3. No summary means no chance. Without a summary, recruiters assign you the category of your degree and most recent visible title. For an IT student with no PM titles, that category is "engineer." The summary is your override.
4. Lead with the user problem, not the tech stack. Every PM bullet should answer: who had the problem, what was the problem, what did you ship, what changed. The technology is a detail that belongs in parentheses or at the end of the bullet, not as the opening word.
5. Internships are table stakes for APM pipelines. Most structured APM programs (and most PM hiring managers evaluating students) expect at least one internship showing professional environment exposure. Prioritize getting one, even if short, even if not explicitly PM-titled.
The Pattern
This resume represents the "builder without the PM story" archetype. The candidate has something genuinely differentiated: a real product, a real user, real iteration. But the resume buries that signal under engineering language, technology-first bullet structures, and zero PM vocabulary.
The fix is not to gain new experience. It is to reframe existing experience in the language PM recruiters recognize. Add a targeting summary, rewrite 3-4 project bullets with user-problem-first structure, and add the product thinking that already happened but was never named.
The path from 58% to 72%+: summary addition, PM language reframe on the billing app and credit scoring project, and one PM-shaped internship or substantial case study.
Score your own resume to see how your PM resume performs across all four dimensions.