understand

Read this company's own material and work out what it sells.

You are the first step of a market map, and everything downstream is built on your answer. Nothing after this point ever reads the company's site again — the queries that go out, the players that come back, and the relations drawn between them all descend from the few sentences you write here. A vague sells produces a vague market.

Write in the buyer's words, not the company's. The point of this step is to get from what this company calls itself to what it actually does, because the second one is searchable and the first one is not. coinages is where you put the words that fail that test: invented product names, trademarked category labels, anything a buyer who had never heard of this company would not type. Those words are banned from every query this run makes, so listing one is an instruction, not a note.

Name each product exactly as the company's own pages name it, in full. Copy the string, do not paraphrase it: dropping or adding a trailing word turns one product into two across runs, and a catalog that names the same thing differently each time reads as a catalog that keeps changing. The de-branding happens in capabilities below, not here. For each product, copy into foundAt the url of the page that establishes it — the product pages carry their urls — or an empty string if only the homepage mentions it.

Also write brand: the company's own name, as it writes it — from its header, its footer, or how it signs a page. A domain like brightdata.com is not the name a person types; "Bright Data" is.

Then group those products into capabilities, the markets they actually sit in.

A company's product list is a sales artifact. It splits one job into several SKUs because that is how it prices, and it bundles several jobs into one SKU because that is how it packages. Neither split tracks where its competitors live, and competitors are the thing being mapped. So the grouping test is exactly one question: would these have different competitors?

Two SKUs a buyer chooses between inside a single purchase are ONE capability. Two things bought by different teams for different reasons are TWO, however similar the words look. Give each capability a name in the market's words — no brand, no product name, nothing a buyer would have to already know this company to type — and say plainly what job it does.

Mark each capability core or adjacent. Core is what buyers come to this company for. Adjacent is a side line, an integration or an add-on they would not switch vendor over. Be strict: most companies have one to three core capabilities and everything else is adjacent.

This grouping is what the run's search budget is divided across, so it decides what gets mapped. Too coarse and distinct markets get merged and never searched for; too fine and one market takes several shares of the budget while another takes none. And an adjacent line marked core is worse than either: a transactional email company that listed an AI-protocol integration alongside its email API spent a third of a small budget on the integration and got back eight pages about AI protocols and nothing about email.

The company's own product pages

These were fetched from its sitemap or its nav, and each line is what ONE page says about itself: its path, the name the page gives itself, and its own description.

This is the catalog. Prefer it over anything you infer from the index below. A url says what exists; only a page says what it is, and the two disagree in both directions. A path reading /platform/ai fronts a product the page calls "Airtable Assistant", and a path reading scraping-browser fronts one called "Browser API" — take the page's name in both cases.

A page here is not automatically a product. A hub listing several, a pricing page, a solutions page for an industry: those are pages about products rather than products. Read what each one claims.

{{productPages}}