Tallo's resume builder worked, in the sense that students could build a resume and export it. But it was an island. It read the student's profile once, when the resume was created, and never looked at it again. Edits didn't flow back, and getting the finished resume onto the profile meant downloading the file and uploading it again by hand. Most students who built a resume never made it through that last step.
I owned the research, strategy, and prioritization for the new resume builder, along with the roadmap and the epics and stories behind it. Then another PM took over execution, which freed me up to focus on the next major initiative. This case study covers the part of product work that happens before anyone opens a design file.
Starting With Whether a Resume Was Even the Right Artifact
The audience was Tallo's career starters – 18-to-20-year-olds who skipped college and are applying to frontline and early-career jobs. They share a resume-sized problem: they don't know how to name what they're good at. Someone who's run a register for two years doesn't think of that as a skill. Someone else researches every option and freezes. And plenty of them have learned to treat any tool that asks for their information as a possible scam.
Resume builders were a crowded category, and one developer wasn't going to out-build companies that do nothing else. So before writing anything, I wanted to answer a more basic question: for this audience, is a resume even the right thing to build?
I ran a desk-research project across nine threads: how frontline and hourly hiring actually works, how applicant tracking systems read resumes, file versus link versus structured data, which output formats employers can ingest, the evidence for tailoring a resume to a job posting, teardowns of AI resume builders and auto-apply tools, and platforms built for job seekers without degrees. I ran it with my AI-assisted research workflow, with a fact-check pass over every claim.
What the Research Changed About the Product
The biggest finding was a split by job tier. For the frontline jobs these users apply to now, the resume barely matters. Large employers route applicants through structured forms that ask about availability, distance, and work authorization, and resume polish ranks well below all of that. But for the roles they'll grow into, the resume file is still the gate. A resume builder for this audience has to serve the job they want next, not just the one they're applying to this week.
The second finding was that the friction isn't document quality. It's typing the same information in again and again, and that showed up across every thread. Tallo's own download-and-re-upload step was one small instance of a pattern the whole category had. That led to the principle the program was built on: the file is an output, not an input. The profile should be the source of truth, and the resume should be one view of it. Or, as I put it in the first epic, "A resume isn't a separate thing a 19-year-old should have to keep in sync by hand."
The research also set limits. Tailoring a resume to a job posting has decent evidence behind it for structured white-collar roles and no controlled evidence at all for frontline ones. AI writing help raises callbacks, especially for workers with less formal education, but recruiters are already wading through AI-generated applications. The answer that fit both was AI that amplifies the student's own words instead of writing new ones for them.
And the competitive teardown made the differentiator clear. Many popular resume builders let you build for free and then put the download behind a trial that auto-renews, assume a degree in their templates, and work best on a desktop. For an audience without degrees, mostly on their phones, and quick to spot anything that feels like a trick, that turned into simple rules: every export is free, the download always works, and there's no paywall on the way out.
Three Phases, Ordered by Dependency and Risk
I structured the work as three epics, each behind its own feature flag so the team could turn them on independently.
- Connect the resume to the profile. The resume fills live from the profile, with labels showing where each part came from. Edits can go back to the profile one field at a time, always confirmed and never silent, and publishing to the profile takes one tap.
- Import an existing resume. A student uploads a PDF, a Word file, or a photo of a printed resume, reviews and corrects what was read, and gets a private draft. Nothing reaches the profile until they choose to commit it, and a commit fills empty fields and flags conflicts instead of overwriting them.
- Say it the way employers search. Suggestions that work the student's skills into their own descriptions, in the terms recruiters search for, with accept, keep mine, or edit on every one.
The order came from dependencies, not excitement. Phase 3 is the most interesting feature and the clearest differentiator, but it's also the riskiest, since the tailoring evidence doesn't exist yet for frontline roles, and it only works on a profile that has something in it. Phase 1 makes the profile the source of truth that the other two depend on. Phase 2 fills thin profiles, because "a live view of a sparse profile is a sparse resume." So Phase 3 went last and was framed as a measured pilot.
Rules That Protect a Skeptical User
Several of the most important decisions were about what the product would never do. Import was draft-first and never wrote to the profile on its own. Writing automatically would have been faster, but parsing is imperfect, especially from a photo, and a profile that quietly rewrites itself reads as the product acting without permission – exactly the thing this audience is watching for. "Bringing a resume in is fast. Changing the profile stays deliberate."
The language help had its own lines. Job titles stay fixed, "because a title is a fact and changing it edges toward a lie." There's no invented experience, no inflated numbers, and no generic AI copy. "The student stays the author. We just help them find the word."
The cuts were deliberate, too: one fixed template that applicant tracking systems can read, instead of styling options; one resume on the profile, with other versions kept as drafts; no auto-apply and no nudges to send more applications, because the research showed returns drop off once someone is spraying applications everywhere.
Epics Built to Be Handed Off
I wrote the three epics in HOSKRs, the format I use for most product work: a hypothesis, objectives, signals, and key results, with a HEART table (happiness, engagement, adoption, retention, task success) for the signals. I walk through how the format works in a video, Using HOSKRs and HEART to Create User-Centric Performance Indicators. Each epic also named its user goals per persona, its business goals, its non-goals, open questions, and risks with mitigations. The 17 stories were problem-first, with outcome-shaped acceptance criteria, non-functional requirements kept separate, the analytics events each story needed, and design guidance written for the designer rather than pixel specs.
Each phase had one make-or-break metric. The step from building a resume to putting it on the profile wasn't tracked yet, so instrumenting it was part of the first phase's scope instead of an afterthought. You can't learn from a launch you can't measure.
I groomed the first phase with engineering and design, and then another PM took over execution so I could move on to the next major initiative. They inherited the research, the reasoning behind every phase, and a backlog that explained itself. The roadmap the team is building from is the one I handed over, and pieces of it are already live in Tallo, like uploading an existing resume.
What I'd Carry Into Any Discovery Project
The most useful question in this project came before any feature idea: is this the right artifact at all? The answer was "sort of," and the nuance changed the architecture. A file-first builder with better templates would have been the obvious move, and it would have polished the part that mattered least.
I'd also write every epic as if someone else will execute it, because sometimes someone else does. The reasoning is the part that survives a handoff. Stories without it are just a list of tasks, and the next PM has to rediscover everything you already learned.
FAQ: Building a Resume Builder for Young Job Seekers
Do resumes matter for entry-level and frontline jobs?
Less than most people assume. Many large employers of hourly workers use structured application forms, and factors like availability and distance matter more than resume polish. But the resume is still required for many of the roles young workers grow into, so a good builder serves the next job as well as the current one.
Should a resume builder use AI to write the resume?
For this audience, AI should amplify the student's own words rather than generate new ones. AI writing help can raise callbacks, but recruiters are wary of generic AI copy, so suggestions should stay grounded in the student's real experience, keep facts like job titles fixed, and let the student accept, keep, or edit every change.
How do you phase a feature like this?
By dependency and risk. Build the foundation everything else needs first, which here meant connecting the resume to the profile. Put the riskiest, least-proven feature last, framed as a measured pilot, and give each phase its own feature flag and its own make-or-break metric.
Related Case Studies
- Building a Career Scorecard and Job Recommendations for Career Starters at Tallo – another feature built on the same research into career starters.
- Unsticking Tallo's Stalled Job Page Migration – how cutting launch scope got Tallo's job pages into the product.
- Designing a Soft Gate for Email Verification at Tallo – another trust-first design decision for the same audience.
- Tallo: From Months of Debate to a Shipping Roadmap – the strategy work on fieldway.org that defined Tallo's career starter audience.