Most teams read an AI answer for one bit of information: are we in it. That throws away the more useful half. The words the assistant uses to describe you, and the words it uses for everyone else, are a compressed summary of how your category is publicly written about. You can extract that summary in an afternoon, with no research budget, as long as you are clear about what it is and what it is not.
What an answer's language actually reflects
An assistant producing a category answer is drawing on some mix of associations learned during training and documents retrieved at answer time. Both are made of published text: vendor sites, review platforms, roundups, analyst commentary, forum threads, documentation, press coverage. When a model says a product is "aimed at enterprise teams" or "known for its integrations," that phrasing came from somewhere in that written record.
So the answer is a readout of published description. It is not a readout of buyer belief. Those two things overlap, because buyers read the same material, but they are not the same and treating them as interchangeable is the mistake that makes this technique dangerous rather than useful. Buyers hold opinions formed in demos, in procurement fights, and in conversations you were never part of. None of that is in the corpus.
The useful framing is that this method tells you what a well-read outsider would conclude about your category from public sources. That is a real and specific thing to know. It is also exactly the input available to a buyer who is doing early research without talking to anyone, which is an increasing share of early research.
Prompts that surface framing rather than rankings
Ranking prompts ("what is the best X") produce lists and encourage you to read the list. Framing prompts produce prose and encourage the model to characterize. You want the second kind, and you want them phrased the way a buyer thinks rather than the way a marketer does.
Useful shapes, adapted to your category:
- Category definition. "What is [category] and what do these products do?" Tells you the boundary the market draws, which may not be the boundary you draw.
- Buyer segmentation. "Who is [product] for, and who is it not for?" The "not for" half is where the sharpest attributions live.
- Differentiation. "How is [product A] different from [product B]?" Surfaces the axis the public record thinks the category competes on.
- Objection surfacing. "What do people complain about with [product]?" and "What should I watch out for when choosing [category]?"
- Substitution. "What do teams use instead of [category]?" Reveals the real alternative set, which is often a spreadsheet or an internal build rather than a competitor.
- Trigger. "When does a company start needing [category]?"
Run each across the models you care about, and run each several times, because output varies between runs. Vary the phrasing too. If "affordable [category]" and "[category] for small teams" produce different casts of characters, that difference is itself a finding about how the market is segmented in writing.
One discipline throughout: you are collecting language, not scores. Record the full answer text verbatim, along with the model, the date, and the prompt exactly as issued. Paraphrasing at collection time destroys the data.
Coding the attributes assigned to each competitor
This is the part that turns reading into research. Coding means converting prose into a structured record you can count. Do it with a simple scheme and apply it consistently.
For every mention of any company across all your collected answers, log one row:
| Field | What goes in it | Example value |
|---|---|---|
company | Who is being described | Competitor B |
prompt_id | Which prompt produced it | P-04 |
model | Model and version | (as recorded) |
run_date | Date of the run | (as recorded) |
attribute_phrase | The exact wording used, verbatim | "better suited to larger teams" |
attribute_code | Your normalized category for it | segment-enterprise |
valence | positive / neutral / negative / limiting | limiting |
is_comparative | Whether it was stated relative to another product | yes |
Build the attribute_code list from the data rather than in advance. Read fifty phrases first, group them into codes, then apply the codes to everything. Four to eight code families usually cover a category: segment, use case, price posture, ease of adoption, depth or sophistication, integration breadth, support model, maturity. Add one for anything that keeps appearing and does not fit.
Two rules that keep the coding honest:
- Code the phrase, not your reading of it. "Popular with startups" is segment-smb, not "not enterprise-ready," even when you suspect that is the implication. Store the interpretation separately if you want it.
- Have a second person code a sample. Take ten percent of the rows, code them independently, and compare. Where you disagree, your codes are ambiguous and need splitting. This is cheap and it is the difference between a finding and a vibe.
Then count. Frequency of each code per company, across prompts and runs. Because you logged the run date and model, you can also see whether a code is stable or only appears in one model's output, which matters for the next section.
Spotting the gap between your positioning and your description
Put your intended positioning next to the coded description and look at four things.
Absence. Attributes you consider core that no answer ever assigns to you. If your entire strategy rests on being the fast-to-implement option and implementation speed never appears in any description of you, the public record does not contain that claim in a form anyone has picked up.
Substitution. Attributes assigned to you that you did not choose. This is the most common finding and the most useful. It usually means one prominent source — a review platform's category placement, an old roundup, your own pricing page — is doing more descriptive work than your positioning document.
Collision. Attributes assigned to you and to a competitor in identical language. If three companies are all "good for growing teams," the public record does not currently distinguish you, whatever your deck says.
Asymmetry. Where the "not for" and complaint prompts assign limits to you that they do not assign to others, or vice versa. Limits are stickier than strengths, because they get repeated in comparison content.
Before you act on any of these, check stability. A pattern that appears across multiple prompts, multiple runs, and more than one model is worth taking seriously. A striking phrase that appeared once is a single sample from a variable system and means nothing on its own. This is the single most common way teams misuse this technique: one memorable answer becomes a strategy meeting.
Turning findings into messaging work
The output of the analysis is a small set of statements about the gap, each with a concrete next action.
- Absence points at publishing. If a claim is not in the public record in a citable form, the work is to put it there, with substantiation, somewhere retrievable. This is the same job described in category definition is a strategy, approached from the messaging side.
- Substitution points at the source. Find the specific published material carrying the wrong framing, starting with your own pages and your profiles on third-party platforms, and correct what you control.
- Collision points at sharpening. Undifferentiated language usually means the differentiator is real but has never been written down in specific enough terms to be quoted.
- Asymmetry points at either substantiating a rebuttal or accepting the limit and qualifying who you are for.
Feed all four into the same document your positioning lives in, dated, with the prompt set attached. Six months later the re-run is only meaningful if you can reproduce the original conditions. Running this alongside a structured competitor teardown gives you the visibility picture and the language picture from the same collection pass.
The limits of this as research
Stated plainly, because the technique is easy to over-trust.
- It is not primary research. It cannot tell you what buyers want, what they will pay, why they churned, or which objection actually killed a deal. Only talking to customers and prospects does that. This method is a complement to interviews and win-loss analysis, never a replacement, and any plan that swaps one for the other is worse than the plan it replaced.
- It reflects the past. Training data and indexed documents lag the market. A repositioning from last quarter will be underrepresented.
- It is biased toward the loud. Companies with more published coverage get richer, more confident descriptions. Description volume is not market share.
- It varies. Same prompt, same model, different answer. Every conclusion needs to survive repetition or it is noise.
- It can be wrong about facts. Models state incorrect things about products. If an answer asserts a factual error about you, that is a correction problem, not a positioning finding, and it belongs on a different track.
- The corpus is not neutral. Some sources are heavily weighted in what gets retrieved. You are partly reading those sources' editorial choices.
Treat the output as a hypothesis generator that costs an afternoon. Validate the hypotheses with people.
In Plain English
An AI answer's wording is a compressed summary of how your category is described in public writing. Collect answers to framing prompts, log every attribute phrase verbatim, code the phrases into a small set of normalized categories, and compare the result to your intended positioning. The gaps tell you where the public record disagrees with your deck. It costs an afternoon and no budget.
This helps founders, product marketers, and category leads who need messaging insight without a research line item. Use it before a positioning refresh, before a competitive launch, and as a dated re-run every couple of quarters. Do not use it to replace customer interviews. Next step: write six framing prompts, run each five times across two models, and code the first fifty attribute phrases. More on reading answers as market intelligence is on competitive intelligence.
Use the briefing template to record dated changes in how assistants describe categories and their implications for positioning work.