To discover the questions customers ask before they know your category exists, investigate the last situation that made them seek help. Record what happened, what they tried and what they needed to decide. Keep their words separate from your interpretation. A question about a stalled request may deserve an explanation of responsibility before it deserves a page about request-management software.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. AEO concerns how a business’s information appears in answer engines; GEO concerns its representation in generative AI responses. This work begins before prospective customers adopt a business’s service vocabulary. ScaleGrowth Digital publishes this article; its team brings years of experience in organic growth marketing, alongside AI Native for prompt discovery and answer measurement across multiple large language models, and OGOS, the Organic Growth Operating System, for on-page requirements and content briefs.
Start with the situation that creates the question
Consider a fictional software company that sells request-routing software. It wants to reach operations staff who coordinate internal requests through email and spreadsheets. The company could begin with category terms such as approval automation. That would leave an earlier uncertainty unexplored: how a person describes the problem before deciding that software is relevant.
In this fictional scenario, a request is delayed because the requester cannot tell who must act next. The invented question is: “How do I find out who is holding up a request without chasing everyone?” This is illustrative language, not a customer quotation. The important distinction is between finding the next responsible person and buying a tool. The first can lead to the second, but it need not.
The decision-changing fact would be the source of the uncertainty. Perhaps responsibility is already agreed, but updates are scattered across messages. Alternatively, nobody has authority to name the decision-maker. Those situations may sound alike in a keyword list. They require different explanations, and a tool cannot reveal an agreed owner if that agreement does not exist.
Collect customer language without supplying the answer
Recruit prospective users around a recent experience of coordinating a request, rather than around an interest in approval software. Include people whose existing approach worked. If recruitment admits only people already shopping for the category, the research cannot reveal much about the language used before that decision.
Build the interview around a specific episode: “Take me through the last request you needed someone else to act on.” Follow the sequence of events. Ask what the person did when the request stopped moving, what information they looked for and what made the situation worth addressing. These are proposed interview prompts, not questions already put to participants. Introduce the product or category only after that account, if a later part of the research needs it; mark where the introduction occurred.
The GOV.UK Service Manual on in-depth interviews recommends open, neutral questions and attention to concrete experiences. For this research, that means leaving terms such as automation out of the opening prompt. A participant who repeats a term after hearing it from the interviewer has supplied different evidence from someone who introduced it independently.
Before a session, explain its purpose, recording arrangements, data use and retention, and how participation can stop. Retain the consent record with the material it covers. The GOV.UK consent guidance provides a useful research reference for those arrangements; the organisation still needs to determine its applicable data-handling requirements. Consent to take part should not be treated as permission to publish an identifiable quotation.
In the working record, distinguish an exact excerpt from an interviewer summary and an analyst interpretation. For recorded sessions, attach the date, participant code and recording time to the excerpt. Keep the surrounding question, too. It shows whether the wording arose spontaneously or followed a category cue. If only notes are available, identify them as notes and do not reconstruct a polished sentence as verbatim speech.
Map the emerging problem before naming the category
A need-state map connects a situation to the information someone needs to move forward. Its proposed unit is an episode, not a keyword. For each episode, retain the trigger, exact language or labelled notes, current workaround, unresolved uncertainty and desired outcome. Add the analyst’s interpretation in a separate field, along with an alternative explanation and the content decision it would change. A map based on recorded language would need real consented sessions and their supporting records; the fictional example here does not supply that evidence.
Applied to the fictional request, the trigger is an approaching internal deadline. The workaround is sending follow-up messages. The uncertainty is who must act next. One candidate interpretation is that an agreed owner is hard to find; the alternative is that no owner has been agreed. A useful follow-up would establish what happened when the requester asked for a name. That missing detail determines whether the answer should explain how to expose an existing handoff or how to assign responsibility.
Group episodes when the uncertainty and needed decision match, even if the wording differs. Keep episodes apart when the same phrase hides different problems. A complaint about chasing requests could concern missing ownership, missing status information or a decision that has already been made but not communicated. A single category label would conceal those differences.
Do not turn the number of mentions in a small interview set into a market-demand estimate. Instead, record which independently recruited participants supplied each observation, which episodes contradict the interpretation and where the research is still thin. Someone who finds the owner easily but cannot obtain a decision is a useful counterexample to an ownership explanation. Preserve that episode rather than forcing it into the preferred cluster.
A practical handoff condition is that a reviewer can start with a proposed content topic, locate the supporting excerpt and its context, and explain why the topic addresses that episode. The reviewer should also be able to identify what finding would change the recommendation. If the only support is a model-generated question or an analyst’s rewritten phrase, the topic remains a hypothesis for research.
Let the needed decision shape the content response
For the fictional software company, a candidate article could answer: “How can I tell who needs to act on an internal request?” It would explain how to identify the current owner, distinguish a missing update from an unassigned decision and choose the next action. It could include an example handoff record containing the request, the responsible role, the next action and the status location. These are proposed content requirements, not findings from interviews.
The route to software should depend on that explanation. If the organisation has not assigned responsibility, the page should help it make that decision. If responsibilities exist but the same handoff information is repeatedly lost across channels, a category explanation may become relevant. The software company would then need to show how its actual product handles that specific problem. The interview alone would not establish product fit.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter III, “The Funnel Rewired,” of their jointly authored book The Discovery Reset: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.”
For this example, the practical consequence of their argument is to avoid treating a category page as the only useful destination. A person may need an answer about a stalled request before a product comparison makes sense. The same need-state map can guide a problem explanation, a category explanation and a product page, while keeping the question each answers distinct. The book’s framework does not establish where any particular customer encountered those answers.
ScaleGrowth’s relevant work would connect that research to specific content decisions. Experienced organic growth practitioners can distinguish a question about responsibility from a question about software selection. AI Native’s prompt-discovery capability can support further exploration, while its multi-model answer measurement can examine responses to declared questions. Neither activity substitutes for evidence of what prospective users actually said. OGOS can support the resulting on-page requirements and briefs. A defined handoff is needed to carry the research decisions into each system’s work.
For a business that needs this work, the useful starting scope is a consented interview round, a need-state map linked to the original records and a content brief for a supported problem. ScaleGrowth’s content service is a relevant destination for the briefing work. The research should first establish whether the business needs a new page, a clearer existing answer or further investigation.
Assess the first content draft against the episode that justified it. Can it help someone distinguish scattered updates from unassigned responsibility and take the appropriate next action? If it introduces software before resolving that uncertainty, revise the answer. That is a concrete acceptance condition for the proposed content, not a prediction of traffic, recommendations or sales.
References
Using in-depth interviews, GOV.UK Service Manual
https://www.gov.uk/service-manual/user-research/using-in-depth-interviews
Getting informed consent for user research, GOV.UK Service Manual
https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research
Content Services, ScaleGrowth Digital
https://scalegrowth.digital/services/content/