I think a lot of growth teams lose the user in the gap between what was said and what was meant.
The user types one thing into search.
They click a page that seems close enough.
They hit a signup flow that uses different language.
They enter a product that names the same job in a third way.
Then lifecycle shows up a day later and describes the whole thing in a fourth dialect that sounds suspiciously like the org chart.
Nobody on the team thinks they changed the story.
The user usually does.
This is one of those problems that hides in plain sight because the words all feel adjacent. The product team says workspace. The user says project. Marketing says campaign. Support hears task. Lifecycle says setup. Sales says rollout.
Each word is defensible on its own.
Together they create drag.
I keep coming back to Jakob Nielsen’s heuristic on match between the system and the real world. The useful reminder is not only that jargon is bad. It is that products work better when they speak in concepts familiar to the user instead of asking the user to learn the company’s private vocabulary first.
That sounds like table stakes. In practice, growth work violates it all the time.
A lot of funnel loss is really a translation problem
We often analyze drop off like it came from friction alone.
Sometimes it did.
Sometimes the user is still moving, but the language stopped carrying the same meaning.
A query says organize interview notes.
The landing page says knowledge hub.
The onboarding flow says create a workspace.
The empty state says connect sources.
The lifecycle email says centralize team intelligence.
None of those phrases are necessarily wrong.
But they are not interchangeable in the mind of a hurried user trying to solve something before lunch.
The NN group piece on information scent is useful here because it explains how people choose where to go next from the cues in front of them. If the label, surrounding context, and prior experience all signal that a link or next step is likely to help, people move. If the scent weakens, they hesitate or leave.
Growth teams usually apply that thinking to navigation and CTA copy.
I think it belongs across the whole journey.
Search snippet.
Headline.
Form label.
Empty state.
Success message.
Reminder email.
These are all cue surfaces.
If each one translates the job slightly differently, the scent degrades.
The user starts spending energy on interpretation when they meant to spend it on progress.
Good growth work preserves the user’s meaning, not only their click
This is one reason I still return to Jobs to Be Done. A job is not just a keyword bucket. It is the progress someone is trying to make in a real situation.
The vocabulary around that progress matters more than teams often admit.
Words carry assumptions about scale, urgency, ownership, and expected payoff.
Project can feel finite.
Workspace can feel administrative.
Plan can feel strategic.
Task can feel tactical.
Campaign can feel like marketing software even when the user is just trying to send one decent email.
When the product quietly swaps in its own preferred term, the user has to do translation work on top of product work.
That tax is rarely logged as a bug.
It still costs conversion.
I think of this a little like museum label writing.
A curator may have a technically precise internal taxonomy for the archive. The visitor still needs a label that helps them orient quickly and care about what is in front of them.
Or like a trail map.
The ranger may know the official classifications, route histories, and maintenance codes. The hiker still needs to know where the path starts, how hard it is, and whether it leads toward the view they came for.
Products have the same obligation.
Internal accuracy matters.
But the first duty of product language is orientation.
Search is where the language debt often begins
This is especially true in growth because acquisition often sees raw user language first.
Search queries.
Ad copy tests.
Landing page heatmaps.
Support tickets from confused evaluators.
Call transcripts from buyers trying to describe the mess they are in.
That is valuable material.
Then somewhere between acquisition and product, the language gets cleaned up into a more platform friendly or category friendly vocabulary.
Sometimes that cleanup helps.
Sometimes it sterilizes the useful signal.
Google’s own guidance on creating helpful, reliable, people first content is a decent reminder that content should exist to benefit people, not just ranking systems. I think the same instinct belongs inside the product. The point is not to sound more sophisticated than the user. The point is to help the user keep moving toward the job they actually came to do.
This is also where plain language earns more respect than it usually gets in product circles. The Digital.gov plain language guide is written for public service teams, but the principle travels well. Clear language reduces interpretation effort. That is not only a writing virtue. It is a conversion virtue.
The artifact I like is a translation table
When a team has decent traffic and decent intent but weak activation quality, I like writing a translation table.
Not a giant messaging house.
Not a full taxonomy overhaul.
Just a working artifact for one blunt question.
Are we still speaking the user’s language at each step where they have to decide whether to continue.
Translation table
- Entry source or surface
- Exact user phrase from query, interview, sales note, or support ticket
- What the user likely means in plain English
- Product term currently used at this step
- Where the meaning drifts, narrows, or sounds more abstract
- Better wording for this surface
- Proof that the new wording helps orientation or action
- Owner
That is enough.
The point is not to create one blessed glossary for the entire company.
The point is to make the translation work visible before the user has to do it alone.
What changes once the table exists
A few useful things usually happen quickly.
Landing pages stop chasing cleverness for its own sake because the team has to preserve the phrase that carried intent into the session.
Onboarding gets more honest because each label has to justify why it is clearer than the words the user already brought.
Lifecycle gets better because reminders can reconnect people to the job they were trying to finish instead of reintroducing the company category from scratch.
Support gets less lonely because repeated questions stop looking like isolated confusion and start looking like evidence of language drift.
Experiment design improves too.
A copy test is easier to read when you know whether the variant is clarifying the user’s own job or merely replacing it with shinier jargon.
That distinction matters.
Language can increase clicks while making comprehension worse.
I do not think the goal is literal repetition
This does not mean every surface should use the exact same noun forever.
Sometimes the product needs to get more precise.
Sometimes a query is messy and the product needs to sharpen it.
Sometimes the internal model really does need one canonical term for permissions, billing objects, or data structures.
That is fine.
The issue is not translation itself.
The issue is unacknowledged translation that asks the user to infer too much too early.
A good handoff can refine the language while still feeling like the same idea.
A bad handoff makes the user wonder whether they clicked into a different product than the one they thought they found.
I think a lot of activation problems live inside that doubt.
Where I would start in practice
I would pick one commercially important path with visible intent.
Maybe a high intent SEO page.
Maybe a paid landing flow for a use case the team cares about.
Maybe an onboarding path that converts well enough on paper but produces weak retained behavior.
Then I would pull a small set of evidence at the same time.
- search queries or ad language
- landing page copy
- onboarding labels and empty states
- lifecycle messages tied to the first week
- support tickets from the same path
Then I would mark where the user’s phrasing gets translated, polished, abstracted, or quietly replaced.
The point is not to shame the copy.
The point is to see whether the product is keeping faith with the user’s original meaning.
That is often where product judgment shows up.
Not in a brilliant headline.
In the quieter decision to keep the language close enough to the job that the user never has to stop and reinterpret what they came for.
The craft
One of the reasons I like growth product work is that it borrows from places that do not obviously belong together.
Search behavior.
Service design.
Support transcripts.
Information architecture.
Editorial judgment.
A bit of anthropology.
A bit of translation.
A bit of humility about how much meaning a single word can carry.
That last part matters.
Teams often want the perfect framework or the clever growth insight.
Sometimes the better move is simpler.
Keep the user’s words alive long enough for the product to prove it understands them.
That is what I like about a translation table.
It helps the team notice where the company started talking to itself.
And it gives you a practical way to get the conversation back on the user’s side.
