Resume Teardown #57: 3 Years in Enterprise Automation, 49% Score, Wrong Framing
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 technical consultant with 3 years of enterprise workflow automation at recognizable firms, including a B2B application for a global asset management firm, scored 49%. The problem is not the experience. The problem is that every bullet describes what was built, not what was owned, decided, or improved. This is a textbook "right work, wrong framing" resume.
The Resume
Background: Technical Consultant at a Big Four consulting firm (current). Previously an Associate Software Engineer at a mid-size IT services company. Before that, a brief internship at a large IT services company. B.Tech from a regional engineering college. Certifications in Appian (senior developer), AWS, Microsoft Azure, and Generative AI Fundamentals.
What looked good on the surface:
- Credible employer brand: Big Four consulting is a strong signal for enterprise PM roles
- Technical depth: Appian, Power Apps, Power Automate, Python, SQL, integrations
- Domain breadth: finance (fund lifecycle management), mortgage (IDP-based loan automation), internal tools (intelligence reporting app)
- Certifications demonstrate active learning and technical credibility
- Awards and client appreciation mentioned in achievements
Score: 49%
The Core Problem: This Reads as a Developer Resume
The biggest issue is visible in the first line of the summary:
"Skilled software developer with 3 years of experience in Appian application development and expertise in Python, Java, and SQL."
This one sentence brands the candidate as an engineer, not a PM transition. Every recruiter reading this will pattern-match to a developer opening, not a product manager opening. The rest of the resume confirms that framing throughout.
The underlying work is genuinely PM-adjacent. Requirements gathering, solution design, stakeholder demos, external system integrations, workflow design, and user experience decisions are exactly the activities that translate to product management. But the bullets describe them in delivery language, not product language.
This is one of the most common patterns we see in technical-to-PM transitions. The candidate is doing real PM-adjacent work. The resume does not reflect it.
Skills: 46% — The Most Damaging Dimension
The skills dimension scored lowest because the resume lists PM-adjacent capabilities but demonstrates none of them as PM craft.
Look at the skills section: Competitive Programming, Analytical and critical thinking, Team management, Critical thinking, Problem-solving, Project planning. These are generic soft skills. "Competitive programming" is an engineering credential. Neither signals product management.
What IS strong here: Appian, Python, Java, Power Apps, Power Automate, SQL, and integration experience. That technical depth is real and valuable for technical PM roles.
The problem: Nowhere in the experience bullets does the candidate show what that technical work enabled for the business or the user. Skills listed without bullets to back them up become noise.
The fix is to remove generic traits and replace them with PM-relevant capabilities the candidate actually demonstrated: requirements analysis, workflow design, stakeholder demos, UAT, integrations, and process optimization. Then back each one up with evidence in the bullets.
Leadership & Impact: 45% — Activity Without Outcomes
Every single bullet on this resume describes a task. Not one describes a result.
"Gather and analyze business requirements to design tailored technical solutions."
"Implement integrations with external systems for seamless data flow and operations."
"Presented project demos to stakeholders, showcasing implemented features and improvements."
These are responsibilities, not outcomes. A hiring manager reading these cannot tell what changed because this person was involved. What workflow was slower before? What was the error rate before the integration? What did stakeholders decide based on the demos?
The third bullet is particularly close to something PM-worthy. Presenting demos to stakeholders and collecting feedback IS a PM activity. But the current framing makes it sound like a ceremony, not an influence event.
Before: "Presented project demos to stakeholders, showcasing implemented features and improvements."
After: "Ran bi-weekly stakeholder demos for a fund lifecycle management application, gathering 30+ feedback points across 3 review cycles. Incorporated 8 scope changes before go-live based on business owner input."
Now the bullet shows: frequency (bi-weekly), volume of feedback (30+ points), decision count (8 scope changes), and business outcome (shapes the product before launch). Same activity, completely different impression.
The Project Sections: A Missed Opportunity
The experience summary includes three full project write-ups: a fund lifecycle manager for a global asset management firm, a ground intelligence application, and a mortgage loan automation system using AI/IDP.
These are genuinely interesting projects. But the write-ups read like implementation notes:
"The PIMCO Fund Life Cycle Manager project encompasses the development of a dynamic application facilitating efficient fund management through a dashboard and settings page."
This describes the product, not the PM work. A hiring manager wants to know: what problem existed before this? Who were the users? What constraints did you navigate? What trade-offs did you make? What improved?
Each of these projects deserves 2-3 PM-style bullets instead of a paragraph description followed by a roles and responsibilities list.
For the fund management application, the PM-framing could be:
- "Gathered requirements from fund operations teams across 3 business lines to define a dashboard supporting 6 configurable document types, task templates, and alert workflows."
- "Designed the data model and record relationships to support scalable user-level customization, reducing manual intervention in routine fund lifecycle tasks."
- "Facilitated requirement sessions and stakeholder sign-off across 4 rounds of reviews, ensuring scope stayed aligned with business objectives before development began."
Same work. But now it reads like someone who owned the product problem, not just the code.
Experience: 62% — The Story Is There, Buried
The experience dimension scored higher than leadership and skills because the raw career trajectory is coherent. Three years across recognizable firms, progressing from intern to associate engineer to technical consultant. The finance and enterprise automation context is a reasonable foundation for technical PM or platform PM roles.
The gap: The resume does not tell the story of increasing product-facing scope. It tells the story of increasing technical responsibility. Those are different stories. One gets you a developer role. The other gets you a PM interview.
The candidate's summary should explicitly frame the transition: why three years of requirements gathering, workflow design, and stakeholder collaboration in enterprise application development translates to product management. That sentence is completely absent.
Domain: 58% — Present but Undeveloped
Finance, mortgage, and enterprise workflow automation are real domains. The projects span them. But the bullets do not go deep enough into what made each domain unique.
What are the business rules in fund lifecycle management that a PM needs to understand? What are the compliance constraints in mortgage loan automation? What were the specific user pain points in the ground intelligence reporting application?
Domain expertise on a PM resume is not about listing industries. It is about showing you understood the specific problems in those industries. Right now, these project descriptions could apply to any generic enterprise application, which weakens the domain signal.
Picking one thread (enterprise automation or financial workflow systems) and making it more explicit would improve this score meaningfully.
ATS Readiness: 43%
This is the second-weakest dimension and will cause problems before a recruiter ever sees the resume.
The main issues:
Formatting failure: Skills, education, certifications, and project details are interleaved into the experience section rather than in separate sections. ATS systems parse by section header. When content is mixed, the parser cannot categorize it correctly. A simple single-column layout with distinct sections would solve this.
Missing PM keywords: The evaluation found some keywords: stakeholder, requirements, cross-functional, Agile, impact, business, user experience. But the following are absent or weak from recent experience bullets: roadmap, strategy, metrics, prioritization, discovery, launch, user research, go-to-market, iteration, trade-off, adoption, backlog. ATS systems rank you lower when these keywords are not reinforced in experience bullets, not just the summary.
Acronyms without explanation: POC, COE, HTPS, and IDP appear without being spelled out. An ATS or recruiter unfamiliar with internal terminology will not map these correctly.
Spelling issues: "Achivements" (should be "Achievements") and punctuation inconsistencies reduce credibility. These are easy fixes.
Dimension Scores
Skills & Tools: 46% — Technical depth is credible but demonstrated as engineering work. PM craft not visible.
Leadership & Impact: 45% — Every bullet is a task. No outcomes, no decisions visible, no before/after context.
Experience & Background: 62% — Coherent technical path at recognizable firms. Adjacent enough to PM to reframe.
Domain Expertise: 58% — Finance and enterprise automation exposure exists, but not developed deeply enough to serve as a hiring hook.
Key Takeaways
1. Your summary is your first, fastest brand signal. "Skilled software developer" immediately closes the PM door. Rewrite it to connect requirement gathering, workflow design, stakeholder collaboration, and enterprise delivery to the PM roles you want. One sentence can change the recruiter's reading frame for everything that follows.
2. Activity bullets and outcome bullets are not the same thing. "Gather and analyze business requirements" describes a task. "Gathered requirements across 4 business units to define scope for a fund management application used by 20 operations staff, reducing manual task tracking by an estimated 30%" describes impact. The first is a job description. The second is a resume.
3. Project write-ups should answer: what problem, who used it, what changed. Long project descriptions that explain what the application does are less useful than 2-3 bullets that answer: what business pain existed, who the users were, what you owned in the solution, and what measurably improved. Strip the implementation notes. Add the product story.
4. Demos and stakeholder sessions are PM proof points, not ceremonies. Presenting to stakeholders, gathering feedback, and adjusting scope are exactly what PMs do. But only if you frame them as influence events, not deliverables. Add who gave feedback, what changed because of it, and what the outcome was.
5. ATS will rank this resume lower before a human sees it. The formatting issue (mixed sections) and missing PM keywords in experience bullets are structural problems. Rebuild the layout with distinct sections, and add prioritization, metrics, discovery, and launch language where it genuinely occurred in your work.
The Pattern
This resume is the "right work, wrong framing" archetype. The candidate has done three years of real PM-adjacent work: requirements gathering, workflow design, stakeholder alignment, integrations, and demo-driven feedback cycles. That work is genuinely valuable and directly transferable.
But the resume describes it entirely in engineering delivery language. So recruiters open a developer resume, not a PM transition resume. The experience is not the problem. The framing is.
The fix is not adding new experience. It is rewriting what is already there: change the summary to signal the transition, convert task bullets to outcome bullets, reframe project descriptions around the product problem instead of the implementation, and rebuild the ATS structure. Three to four hours of focused rewriting would change this score substantially.
Score your own resume to see how your product manager resume performs across all four dimensions.