I think a lot of growth teams spend too much time optimizing paths and not enough time studying vocabulary.
The path matters, obviously.
The landing page matters.
The onboarding flow matters.
The lifecycle message matters.
The search box matters.
But underneath all of that is a quieter question that usually does more damage than the team expects.
Are users describing the problem in the same words the product uses?
When the answer is no, strange things happen.
SEO traffic lands on pages that almost match intent but not quite.
Onboarding copy sounds polished but does not feel like the user’s own mental model.
Internal search becomes a little graveyard of near misses.
Support keeps translating the same confusion back into company language.
Lifecycle messages arrive with terms the user has not emotionally adopted yet.
Nothing is fully broken.
The product just keeps making the user do interpretation work.
I think that is a growth problem.
Search queries are product notes in disguise
One reason I still like search data is that it is unusually honest.
When people type into Google, or into your site search, or into a help center, they are usually not trying to sound smart. They are trying to get unstuck.
That makes query language useful.
It shows you what the user thinks the job is.
It shows you what noun they reach for first.
It shows you what outcome they expect to find.
Sometimes it shows you the exact phrase your product team forgot to adopt because it sounded less elegant than the internal taxonomy.
I think that is part of why Google’s SEO Starter Guide still matters. It keeps pulling teams back toward clarity, structure, and language that helps people find the page they actually wanted. The operational lesson for product work is similar. If users cannot recognize their intent in your language, the experience starts leaking trust before they even click.
That same issue shows up again inside the product.
The user searches for invoice when your product says billing document.
They search for drafts when your UI says workspaces.
They search for templates when you call them blueprints.
They search for cancel when the account page says pause.
Every one of those mismatches is a small tax.
Enough small taxes and the product starts to feel harder than it is.
Information scent is not only a UX idea
I come back often to NN group’s piece on information scent because it explains a simple behavior cleanly. People decide where to go next based on the cues they see along the way.
That is usually discussed as navigation or link design.
I think growth teams should care about it more broadly.
Acquisition channels create scent.
Headline copy creates scent.
Onboarding labels create scent.
Search results create scent.
Emails create scent.
The user is constantly asking some version of the same question.
Does this look like it leads to the thing I came for.
When the scent is strong, movement feels natural.
When it is weak, users do not always complain. They just hesitate, wander, or leave.
That is one reason I do not think query analysis belongs only to the SEO or support side of the house.
It belongs anywhere the product is making promises with language.
A lot of churn starts as a translation problem
I do not mean every retention issue can be solved with better copy.
That would be a silly conclusion.
I mean something narrower and more practical.
Before a user decides whether your product is worth returning to, they usually have to answer a few language questions for themselves.
What is this thing in terms I already believe.
Is the feature I need called what I think it is called.
Does the product understand the outcome I am trying to produce.
Can I recover the thread later using the words I will still remember.
This is where I still find Jobs to Be Done in Harvard Business Review helpful. If the user hires a product to make progress in a situation, then the words they use are not cosmetic. They are evidence about the progress they are trying to make.
When a product loses touch with that language, teams often misread the downstream effect.
They call it poor activation.
They call it low feature discovery.
They call it weak SEO quality.
They call it lifecycle underperformance.
Sometimes those labels are correct.
Sometimes the simpler truth is that the company has built a translation layer that users never asked for.
The artifact I like is a query gap memo
This is not a giant keyword spreadsheet.
It is not a content audit with a grand taxonomy.
It is a small working memo for words users keep using when the product does not meet them cleanly.
Query gap memo
- Exact phrase the user typed or said
- Where it appeared
- What job the user was likely trying to get done
- What the product currently calls that thing
- Where the experience stopped matching the user’s language
- Evidence from search logs, support, interviews, or session replay
- Best fix
- Owner
That is enough.
The value is in forcing the team to see language drift as an operational issue instead of a content nitpick.
Once you keep this memo for even a week or two, patterns usually start showing up.
You may notice that SEO queries, help center searches, and support tickets are all circling the same missing concept.
You may notice that new users keep searching for an outcome while the product is organized around a feature.
You may notice that returning users remember the old term even after the company has rebranded the workflow.
You may notice that lifecycle messages perform worse when they use internal nouns instead of the verbs users actually reach for.
That is rich growth material.
This feels a little like library science and a little like retail merchandising
That mix is part of why I enjoy this kind of work.
Library systems care about classification, synonyms, retrieval, and helping someone find the thing they do not know how to ask for perfectly.
Retail merchandising cares about adjacency, recognition, and reducing the effort required to move from vague intent to a confident decision.
Good growth product work often needs both instincts.
You are not only improving wording.
You are reducing the distance between user intent and product recognition.
That can happen on a landing page.
It can happen in search autocomplete.
It can happen in onboarding labels.
It can happen in help center IA.
It can happen in the subject line of a lifecycle email that finally uses the user’s own framing instead of the company’s preferred terminology.
Search Console and product analytics should talk to each other more often
I like Google’s guide to using Search Console and Google Analytics data together because it pushes in the right direction. Do not treat query data and on-site behavior as separate stories if they describe the same user intent from different angles.
I think product teams should steal that habit.
Bring together
- top external queries
- internal search terms
- zero result searches
- support ticket phrasing
- onboarding drop off moments
- lifecycle engagement by segment
Then ask a less glamorous but more useful question.
Where is the user naming a need that we still have not mirrored back clearly.
That question often produces better roadmap ideas than another round of surface-level funnel commentary.
You might still ship a feature.
But you might also rename a flow, create a bridge page, add synonyms to search, rewrite an empty state, retime a message, or collapse three product terms into one human one.
Those are not trivial edits.
Sometimes they are the difference between a product that feels intuitive and a product that feels like it requires local knowledge.
Why I think this matters more for mid-career product work
Early in a product career, it is easy to think progress comes mostly from bigger levers.
More tests.
More channel ideas.
More onboarding steps.
More segmentation.
Those can all matter.
But at a certain point you realize a lot of leverage is sitting inside the words.
Not brand words.
Not strategy deck words.
User words.
The phrases people type when they are confused, hopeful, impatient, half-informed, or trying to continue something they started three days ago.
Those phrases are a kind of field note.
They tell you what the user thinks they are doing.
When your product meets those phrases well, the experience gets lighter.
When it ignores them, the product starts to feel just a little off in many places at once.
That kind of off-ness is expensive because it diffuses across acquisition, onboarding, activation, support, and retention without looking like one obvious defect.
What I would do in practice
I would start narrow.
Pick one commercially important path.
Maybe a high intent SEO page that drives trial starts.
Maybe internal search during the first week of use.
Maybe account management language around upgrading, pausing, or cancelling.
Then build the memo from a few evidence streams at the same time.
- Search Console queries
- internal site search logs
- support conversations
- sales call notes if relevant
- session replays around search or navigation
Do not start by fixing everything.
Start by finding repeated translation failures.
Then make the smallest changes that improve recognition.
A synonym here.
A headline there.
A better result title.
An onboarding label that uses the user’s job instead of the internal feature bucket.
A lifecycle email that sounds like continuation instead of marketing.
This is quiet work.
It is also some of the most compounding work I know.
The point
If you want a product to feel easier, do not only study where users click.
Study the words they use when they are trying to move.
Those words often tell you where your product is asking for translation, where your growth systems are leaking scent, and where a small language repair could make the whole experience feel more native.
That is not only an SEO lesson.
It is a growth product lesson.
