Job Title and Seniority Normalization: Fixing the Data Behind Your ICP Score

The title field is the least reliable field you have

Ask a hundred people who lead growth at their company to type their job title into a signup form, and you'll get a hundred different strings. "Head of Growth." "Growth Lead." "VP, Marketing & Growth." "Growth @ [Company]." "Marketing." Some will paste their full LinkedIn headline. A few will leave it blank. None of this is a data quality bug in the traditional sense. It's just how people describe their own jobs when nobody's checking their work.

That would be a minor annoyance if job title were a display field. It isn't. It's usually one of the heaviest-weighted inputs into ICP scoring, lead routing, and account prioritization. If "Head of Growth" and "Growth Lead" score differently just because of how someone typed their title that day, the scoring model is making decisions on noise, not signal.

Normalization is the fix: turning a messy self-reported string into a small number of consistent, comparable fields. It's unglamorous work, and it's also one of the highest-leverage things a growth team can do to make ICP scoring actually trustworthy.

Why this breaks scoring downstream

Most ICP models assign points for seniority and function: a VP or Head of role in a target function scores higher than an individual contributor, and a match on marketing or growth scores higher than a match on, say, finance. That only works if the model can reliably tell what someone's title means.

Raw title strings fail this in three specific ways.

Synonyms split the signal. "Head of Growth," "Growth Lead," and "Director of Growth" often refer to the same seniority and function in different companies, but if your scoring rule matches on exact substrings or a short keyword list, only one of them gets credit.

Combined titles confuse function matching. "VP, Marketing & Growth" or "Co-founder & Head of Product" contain two functions in one string. A naive keyword match either double-counts, picks the wrong one, or misses both because the string doesn't match cleanly.

Seniority words don't map consistently across company size. A "Director" at a 12-person startup can be doing individual-contributor work with an inflated title, while a "Manager" at a 3,000-person company might run a 40-person org. Seniority read in isolation, without company size as context, produces a lot of false positives and false negatives in both directions.

The result, if none of this gets addressed, is an ICP model that quietly under-scores good-fit users because their title happened to be phrased unusually, and over-scores poor-fit users whose title sounds impressive but isn't. Sales teams stop trusting the score, and once that happens, they route by gut feel instead, which defeats the point of scoring at all.

What normalization actually means

Normalization isn't lowercasing a string and calling it done. It's decomposing one messy field into three clean ones: function, seniority, and (optionally) a specialty or department tag.

Function

A fixed taxonomy, not a free-text field. Something like: Growth, Marketing, Product, Engineering, Sales, Customer Success, Operations, Finance, Executive/General Management, Other. Every title gets mapped to exactly one primary function, even when the raw string contains more than one. Pick the function most relevant to your product, and store the secondary function separately if you need it for anything.

Seniority

A short, ordered ladder works better than trying to preserve every title variant: Individual Contributor, Manager, Director, VP, C-level/Founder. Five or six levels is usually enough resolution for routing and scoring decisions. More than that, and you're modeling org-chart nuance nobody downstream will use.

Specialty or department tag (optional)

Useful if your product serves a narrow function and you want finer targeting inside it. For example, distinguishing "Growth Marketing" from "Content Marketing" inside the Marketing function, when your product specifically serves growth teams.

Building the normalization pipeline

A workable pipeline has four layers, applied in order, each one catching what the layer before it missed.

1. Clean the raw string

Strip company names, emoji, pipe-separated extras ("Growth Lead | ex-Stripe"), and location tags before anything else runs. This alone resolves a surprising share of parsing failures, because a lot of "unmatched" titles are really matched titles buried in extra text.

2. Match against a curated title-to-role dictionary

Build a lookup table mapping common title strings and their close variants to a function and seniority pair. Seed it from your own signup history: pull the most frequent raw titles in your database, and you'll usually find that a few hundred entries cover 70-80% of your traffic. This dictionary is the highest-leverage artifact in the whole pipeline, and it's worth maintaining deliberately rather than letting it grow ad hoc.

3. Fall back to pattern and keyword rules

For titles that miss the dictionary, use rule-based matching: seniority keywords ("VP," "Head of," "Director," "Chief") mapped to a seniority level, function keywords ("Growth," "Marketing," "RevOps") mapped to a function. This layer is noisier than the dictionary but catches long-tail variants without manual entry for every one.

4. Use an LLM for what's left

Titles that survive both layers unmatched (non-English titles, unusual phrasing, combined roles with no clear primary function) are a good candidate for a model call that classifies the string against your fixed function and seniority taxonomy. Constrain the output to your enum values so you get a clean field back, not more free text. This layer should be the smallest by volume; if it's carrying most of your traffic, your dictionary and rules need more work, not a better model.

Log which layer resolved each title. That single field tells you where to invest next: a dictionary miss rate climbing over time usually means new job titles are showing up in your market and the dictionary needs an update pass.

Adjusting for company size

Seniority should never be scored in isolation from company size. A useful shortcut: normalize seniority into a 1-5 scale, then apply a size-adjusted weight when it feeds into ICP scoring. A "Director" at a 20-person company might get treated closer to a VP-equivalent decision-maker; a "Director" at a 5,000-person company might sit several layers below the actual buyer. This is a small addition to the scoring formula, but it's the difference between a model that's directionally right and one that's precise enough for sales to act on without double-checking.

Edge cases worth handling on purpose

Founders and co-founders. Almost always map to C-level/Executive seniority regardless of the specific function listed, since founders typically make or heavily influence buying decisions across functions at their company.

Fractional and interim roles ("Fractional CMO," "Interim VP Marketing"). Treat these as their stated seniority and function. The "fractional" qualifier affects buying authority and budget, not org-chart position, so it's worth its own flag rather than downgrading seniority.

Agency and consultant titles. Someone whose title reflects their agency role rather than the client company they're signing up on behalf of. If you can detect this pattern (agency domain, title mentioning "consultant" or "agency"), route these separately instead of scoring them against your standard ICP, since the buying dynamics are different.

Students and career-changers. Titles like "Student," "Growth Intern," or blank fields with a personal email domain. These should score low on seniority by default, not fall through to manual review, since manual review doesn't scale once you're past a few hundred signups a month.

Checklist: is your title data normalization solid?

• Every enriched user has a function and seniority field populated from a fixed taxonomy, not just the raw title string.
• The dictionary layer resolves at least 60-70% of your traffic; check this number, don't assume it.
• Seniority scoring is adjusted by company size, not applied as a flat scale.
• Combined titles ("VP, Marketing & Growth") consistently resolve to the same primary function every time, not randomly depending on word order.
• Founders, fractional roles, agency signups, and students each have an explicit handling rule, not a fallback to "unknown."
• You're logging which pipeline layer resolved each title, so dictionary and rule-set staleness shows up as a metric instead of anecdote.
• Someone reviews the unmatched and LLM-classified buckets on a schedule to feed corrections back into the dictionary.

Where this fits

Title normalization sits underneath everything else in a PLG enrichment stack. It feeds ICP scoring directly, but it also shapes teammate discovery (which colleagues get flagged as expansion-ready depends on their normalized seniority), PQL triage (routing rules usually gate on seniority), and lookalike search (seed accounts built from mis-scored users produce worse lookalikes). Get this layer wrong and every model built on top of it inherits the noise.

Groful normalizes function and seniority as part of enrichment, using dictionary matching backed by a model fallback for the long tail, so scoring and routing rules work off clean fields instead of raw title strings. If your ICP scores feel inconsistent and you suspect the title data is the culprit, get in touch or see how it fits into the full enrichment pipeline.