How to tailor your resume to a job description

Start with the responsibilities. Before changing a sentence in your resume, write down what the person hired will need to do. Then check the requirements and any practical conditions, such as location or work authorization, that affect whether you can take the job.

For this example, we're using Help Scout's English-language Sr. Product Analyst posting. The vacancy's current status hasn't been verified; the description is our reference for this exercise. Help Scout's Sr. Product Analyst posting

The posting is a reference for this fictional exercise, not an endorsement or a verified hiring status.

The posting asks for three to five years in SaaS product analytics, strong SQL, and hands-on Mixpanel experience. Hex experience appears among the optional qualifications. Those distinctions matter: Jordan can show SQL and Mixpanel in actual project bullets, while listing the BI tool they've used, Looker, without pretending they've used Hex.

Read your resume beside these notes. Jordan's weekly reporting work deserves some space, but an investigation into stalled onboarding answers more of the questions in the table. That project should move up. A separate experiment can demonstrate another requirement without making the onboarding project carry every claim.

For your own application, note a specific example beside each important responsibility. An empty space is worth noticing. You may have omitted relevant work from your resume, or you may lack that experience. Check your records before deciding which it is. Changing the wording cannot fill a genuine gap.

It doesn't tell us what was wrong, what Jordan did, or what anyone did with the analysis. Before rewriting it, we need the project details. In this fictional case, those details are:

Jordan's employer sold software that let teams build automated workflows. The product dashboard counted a workspace as activated when someone saved a workflow, even if it never ran. Jordan checked the SQL behind the dashboard and compared Mixpanel events with execution records. With the product manager, they agreed to measure activation as a workspace's first successful workflow run within seven days of creation. Jordan documented the definition and tracking requirements; engineers implemented the tracking changes, which Jordan then checked.

With the corrected data, Jordan traced the steps from workspace creation to a successful run. The biggest drop was between saving a workflow and connecting the external app it needed. Support tickets also described confusion about connection permissions. Jordan recommended changes to the setup guidance, and the product manager put that work on the onboarding roadmap. Design and engineering would handle the interface work.

The project record stops at the accepted recommendation. It contains no measured lift in activation, retention, or revenue.

The first bullet shows measurement work. The second gives the product question, the evidence Jordan used, and the decision that followed. Both are more useful than the original line because the reader can see what Jordan contributed.

The ownership is also clearer. Jordan can say they audited the tracking and recommended a change. "Led an onboarding redesign" would claim responsibility for work done by the PM, designer, and engineers. Likewise, "increased activation" would need a result the project record doesn't contain. A recommendation accepted for the roadmap is a concrete outcome worth stating on its own.

When your project does have a measured result, keep the definition attached. Say what changed, over what period, and what the comparison was. If the only confirmed outcome was a decision, a corrected measurement, or a completed deliverable, use that. Adding a percentage because the bullet looks stronger with one creates a claim you'll have to defend later.

You can also replace internal shorthand with language an outside reader understands. Jordan's colleagues might call this the "first-run cleanup." On a resume, "activation tracking" and "onboarding drop-off" explain the work. Keep your actual job title and tools, though. Changing "Data Analyst" to "Senior Product Analyst" would alter the employment record, even if the new title matches the opening.

Two improved bullets won't help much if they're still below a long list of less relevant duties. Put them near the top of Jordan's current role, then consider what else earns space.

Jordan also worked on an A/B test of a setup checklist. One bullet can describe the experiment design and readout. The recurring dashboards need only one line explaining what the product team used them for. That leaves four bullets under the current role, with most of the detail going to the work this application needs.

Keep jobs in reverse chronological order. Within a role, reorder the bullets by relevance. Jordan's earlier scheduling-software role can be shorter, but it should still show the employer, title, dates, and a couple of substantive contributions. Don't pull an older project into the current job to get it higher on the page.

For this particular example, I'd try one readable page first: two jobs, a compact skills section, and education near the bottom. The complete example is short enough to try that without losing the important work. Your resume may need more room. If a second page carries distinct, relevant experience, keep it; if it mostly repeats responsibilities, edit those first. Follow any length or format instructions in the application.

A summary is optional. "Results-driven professional with a proven track record" takes space without explaining Jordan's work. If you use a summary, make it specific enough to help the reader place your experience, then let the job entries provide the detail. Avoid repeating the same project in a summary, an experience section, and a separate project section.