The Market-Map Placement Codebook: In-Category, Adjacent, or Off the Map

This standard is for strategy and research teams, talent-intelligence analysts, and operators building a market map for a strategy, build-or-buy, or investment decision. Market-mapping guides tell you to write a codebook before collecting logos, then never give you one. This guide supplies it. It contains placement tests for In-Category, Adjacent, and Off the Map, a single tie-break rule for primary segment, a public-evidence test for operating status, and a double-coding check with a pass mark. Adopt it as team policy, and two analysts grading the same long list should put the same logos in the same boxes.

What does a placement decision consist of?

Every company in the long list gets three recorded decisions, in a fixed order. First an operating status, then a placement grade, and then, only if the grade is In-Category, exactly one primary segment. Each decision carries a dated public source, so you can defend any row when a stakeholder asks why a logo is or is not on the map.

Terms used throughout:

• Long list (universe): every candidate company collected, before any grading.
• Codebook: the written scope, segment definitions, criteria, and worked examples that keep classification consistent. Umbrex's market-mapping framework describes the step as: "Document definitions and examples (a 'codebook') to ensure consistent classification."
• Shipped product: a product a customer can buy and run in production today, as opposed to one a homepage describes.
• Operating status: whether the company and its product are Live, Zombie, Absorbed, or Closed, judged from dated public evidence.
• Primary segment: the one box on the map where the logo goes.
• Double-coding: two analysts grade the same sample independently, then measure how often they agree.

The order matters:

1. Status comes first, because a closed company does not need a segment and an absorbed product may not need its own row.
2. Placement comes second, so you don't spend time arguing over segments for companies that are only Adjacent.
3. Segment comes last and is decided once.

Shipped-product evidence separates a choice a buyer can make from a pitch. Scope fit asks whether the product does the core job named in your one-sentence scope. The rest of this standard is a way of grading those two axes so that another analyst gets the same result.

In-Category, Adjacent, or Off the Map: the placement criteria

A company is In-Category when it is Live and its stand-alone, generally available product does the core job in your scope sentence, at or above your stated evidence threshold. It is Adjacent when it is Live and ships a generally available product that does a neighbouring job, or that does the core job only as a feature inside something larger. Everything else is Off the Map.

The shipped-product test, borrowed from analyst gates

The clearest published test of whether a company "ships a product" comes from analyst inclusion criteria, not marketing pages. Gartner's Observability Magic Quadrant required capabilities to be "generally available", which it defines as "widely available to all customers for purchase through normal sales channels". It also required the vendor to sell "directly to paying customers without requiring them to engage professional services help," and set a minimum of "50 paying, production (non-beta-test) customers". Its first AI Governance Magic Quadrant required each mandatory feature "as a stand-alone product".

Four of those conditions carry over to any market map:

1. Generally available: purchasable through normal channels, not by invitation or pilot only.
2. No services dependency: a customer can buy and use it without a professional-services engagement.
3. Production, not beta: at least one paying customer runs it in production.
4. Stand-alone: it can be bought on its own. This is the line between In-Category and Adjacent. A feature that only exists inside a larger suite is Adjacent, however good it is.

Analyst gates show what a fixed threshold looks like, and also how much it moves.

The SIEM gate went from 200 to 500 customers in one cycle. "In-category" by analyst standards is a moving bar. Your map therefore has to state its own fixed evidence threshold and as-of date, or nobody can compare it with the next version. Do not copy an analyst's scale gate onto a map of private companies. Those gates deliberately exclude "Innovative niche providers that are technically leading but still small," and those providers are often the reason you are building the map in the first place.

The evidence ladder

No published source says which artifacts count as proof of a shipped product, whether docs, pricing pages, changelogs, or API references. The ladder below is my convention. Your double-coding score is what tests whether it works for your category.

My default threshold for a map of private companies:

• In-Category: the top two rungs (a publicly verifiable paying production customer and a purchase path), plus a dated change record inside the status window.
• Adjacent: the same evidence, for a product that does a neighbouring job or does the core job only as a feature.
• Off the Map: only the claim rung, or no rung reached.

You can raise the threshold, but write it down and date it. The template below puts every judgement call in one place.

SCOPE: [one sentence naming the buyer and the core job the category does]
DECISIONS THIS MAP SERVES: [list each decision, e.g. build-or-buy, target list, entry point]
AS-OF DATE: [date the evidence was gathered]

EVIDENCE THRESHOLD
In-Category: named paying production customer + purchase path + dated change record inside window
Adjacent: same evidence; neighbouring job, or core job only as a feature
Off the Map: claim rung only, out of scope, or not Live

STATUS WINDOW: [length; default = one review cycle]

SEGMENTS (each segment is a box on the map)
S1 [name] | definition: [the job this segment does] | include e.g.: [company] | exclude e.g.: [company, reason]
S2 [name] | definition: | include e.g.: | exclude e.g.:
MULTI-SEGMENT ROW: last resort only; reason recorded per company

TIE-BREAK (apply in order, stop at first rung that decides)
1. Disclosed revenue: one activity above 60% of revenue
2. Only one product passes the shipped-product test
3. Product with the highest evidence rung; if tied, the first product on the pricing page
4. Multi-segment row

PER-COMPANY RECORD
ID | name | aliases/brands | status + date + source | grade | segment | tie-break rung used | evidence rungs + dated sources

How do you assign exactly one primary segment?

Use one tie-break rule with ordered fallbacks. Where revenue is disclosed, use revenue share, as GICS does. Below that come the only stand-alone product, then the product with the strongest evidence, and finally a named multi-segment row. Each rung is observable from outside the company, and you record which rung decided each company.

The tie-break that is best established in public use comes from GICS (the Global Industry Classification Standard). It runs 163 sub-industries on one rule: "A company is initially classified into the GICS Sub-Industry whose definition most accurately reflects the business activity generating more than 60% of the company's total revenue." If no activity reaches 60%, the company goes to "the sub-industry that provides the majority of both the company's revenues and earnings." If that fails too, it lands in "Industrial Conglomerates... or the Multi-Sector Holdings sub-industry." GICS also recognises "earnings and market perception" as important.

The problem is that most market maps cover private companies that publish no revenue split, so the 60% rule usually can't be applied. No published standard supplies an observable stand-in for revenue share, and none uses "the buyer" or "the product the company leads with" as a tie-break. The ordered rule below is my convention. Treat it as a hypothesis that your agreement score either supports or refutes.

1. Disclosed revenue. If the company discloses a revenue split and one activity is above 60%, that activity's segment wins.
2. Only one stand-alone product. If only one of its products passes the shipped-product test, that product's segment wins.
3. Strongest evidence. Otherwise, the product that reaches the highest evidence rung wins. If two products tie, use the one listed first on the pricing page.
4. Multi-segment row. If nothing decides it, place the company in a named multi-segment row, the map's equivalent of the GICS conglomerate bucket. Record the reason.

The multi-segment row is a diagnostic tool, not a convenience. If it grows beyond a handful of logos, your segment definitions overlap, and you need to fix the codebook rather than the companies.

Two structural cases come up on almost every map:

• Subsidiaries. GICS rules that "If a company's subsidiary files separate financials... the subsidiary will be considered a separate entity and classified independently." For a map, the equivalent test is whether the subsidiary sells under its own brand through its own purchase path. If it does, give it its own row.
• Reclassification. GICS changes a code "whenever there is a major corporate action that redefines a company's primary line of business." Apply the same trigger. A pivot changes the segment, but a new tagline does not.

What separates a Live company from a Zombie, Absorbed, or Closed one?

A company is Live only when dated public evidence from inside your status window shows the product can still be bought and is still changing. Closed needs a positive closure signal, because missing evidence is not proof of death and neither is shrinkage. Zombie covers the space between the two.

This is the test where maps fail quietly, because companies usually die quietly. Among products removed from the martech landscape in one year, "84% of the products removed were shut down entirely, not acquired... often without notice."

Shutdown counters undercount as well. Carta recorded 966 shutdowns among its US customers in one year, up from 769 the year before, and AngelList recorded 364 winddowns against 233. Even so, Carta's head of insights, Peter Walker, said: "I bet we're missing a good chunk... There are a number of companies who leave Carta without telling us why they left." Commercial company databases have a status field with four values (operating, closed, was_acquired, ipo) and a separate closed date. How that date is determined is not published. Treat a database status as a lead to investigate, not a verdict.

No one has published a false-dead rate for changelog age, job postings, domain changes, or headcount, so any numeric window is a convention. My default window is one review cycle, and GICS reviews each company "at a minimum... annually." Write the window into the codebook and apply it to every company in the same way.

Absorbed brands and the people trace

Acquired brands do not always leave the map. Gartner gave Infinidat, "now owned by Lenovo," an honorable mention. What decides the row is the structure after the deal. Commercial schemas record whether an acquired company became "combined... division... product... separate_entity... subsidiary," along with an exit date. Use those two fields together.

People data shows absorption that company records hide. In Refolk's index, one US employer string reads "Workday Adaptive Planning", which names a parent and an absorbed product brand in a single label. When the product's team lists the parent in their current employer strings, that is evidence the brand has been folded in. In Refolk you can ask in plain English for the people working on a named product and read their current employers directly. This signal misleads when people keep an old brand in their profile out of habit, so use it to support a dated corporate source, never as a replacement for one.

How do you run the double-coding check and report agreement?

A second analyst codes 20 companies blind, using only the codebook. You then compute Krippendorff's alpha (a chance-corrected agreement coefficient) on the combined label. The map passes at 0.800 or higher. Between 0.667 and 0.800, revise and recode. Below 0.667, rewrite the codebook. Always report percent agreement, alpha, AC1, and the number of companies coded.

Code one nominal label per company. The label set is each segment, plus Adjacent, plus Off the Map. That one label captures both the placement grade and the segment, so a single coefficient tells you whether the codebook works.

The pass marks come from Krippendorff's thresholds for content analysis: "social scientists commonly rely on data with reliabilities α ≥ 0.800, consider data with 0.800 > α ≥ 0.667 only to draw tentative conclusions, and discard data whose agreement measures α < 0.667." The Landis and Koch bands for kappa tell a similar story: 0.61 to 0.80 is "substantial" and above 0.80 is "almost perfect." No published standard is specific to coding 20 to 50 companies into 5 to 12 segments, so these thresholds are borrowed, not purpose-built.

Three rules for the sample:

• Blind means blind. The second coder sees the codebook and the company list, not the first coder's labels or notes.
• Stratify. Include boundary cases, such as suspected Adjacents and possible multi-segment companies, alongside the obvious ones. A sample made up only of clear cases flatters the codebook.
• Report n. A high alpha "on very few units carries little weight." With 20 units, add a bootstrap confidence interval.

Placement agreement: n = [20] companies, double-coded blind against codebook v[x], [date].
Label set: [k] segments + Adjacent + Off the Map.
Percent agreement: [ ]% | Krippendorff's alpha: [ ] (95% bootstrap CI [ ] to [ ]) | Gwet's AC1: [ ]
Result: [Pass at alpha >= 0.800 | Revise and recode, 0.667 to 0.800 | Rewrite codebook, below 0.667]
Disagreements resolved: [count]; codebook changes made: [list]

Who should the second coder be?

People with an exact competitive-intelligence title are rare, so most teams will pair a generalist with a domain specialist. In Refolk's index, exact-title counts look like this:

That is a 38:1 ratio between the US and the UK for the same title, and Competitive Intelligence outnumbers Talent Intelligence in the US by 12.7x. These are exact-title matches, so they undercount everyone doing the work under other titles. My reading of the counts, which is an interpretation and not a published finding, is that a strategy or insights generalist working with a domain specialist is the realistic double-coding pair. That pairing also helps the check: two analysts from different backgrounds test the codebook harder than two specialists who share the same unwritten assumptions.

If your own bench is thin, Refolk is the quickest way I know to find a second coder outside the team who has graded vendors before. Brief them with the codebook only. Giving them anything more breaks the blind.

The placement procedure, step by step

Run these eight steps in order. Write the codebook before collecting any logos, finish the status check before any segment debate, and do not publish without an agreement score. None of the sources gives a duration for any step, so no time estimates are given here.

On the width of step 3, the sources genuinely disagree. One deal-sourcing platform warns that "Filtering too early means you might never see it." VC Careers argues that "A focused map of 30 well-chosen companies with clear segmentation is usually better than a messy list of 300." Both points survive if you keep the universe wide and the published map focused. Whatever you do, do not seed the universe only from analyst reports. Their scale gates exclude the small, technically leading providers by design.

Step 4 follows the standing instruction to "Separate facts from inferences; capture sources and dates for each field." Without the dates, there is nothing to apply the status window to.

How does market-map placement go wrong?

Most placement errors come from trusting a label over current evidence. The label might be a homepage category, a database status, or a past title, and it outlives the activity it describes. Each failure below shows what it looks like and the check that catches it.

1. Taking a homepage claim as proof of a product.

   • Looks like: a "platform" page with no pricing, no docs, and no generally available customers, graded In-Category.
   • Check: apply the GA test. The product must be purchasable through normal channels and have paying production customers, not beta users.

2. A label that no longer matches current activity.

   • Looks like: a company placed by its database category or its old positioning after the product has moved on. In Refolk's index, 4 of 25 sampled "Competitive Intelligence" profiles carried other current titles, including "Retired". Companies drift the same way.
   • Check: grade on dated current evidence, never on the stored category.

3. Reading headcount decline as death.

   • Looks like: a company marked Zombie because its team shrank.
   • Check: live companies are shrinking too, and Series D averages fell 29%. Require an absence signal: no product changes, a closed date, or a removed purchase path.

4. Treating database status as ground truth.

   • Looks like: every company the database marks "operating" goes onto the map unchecked.
   • Check: Carta admits it misses shutdowns, and 84% of martech exits were quiet shutdowns. Confirm "operating" with your own dated evidence.

5. The kappa paradox with a dominant segment.

   • Looks like: one segment holds most of the logos, kappa reads 0.43, and the team throws out a codebook that actually works at 88% raw agreement.
   • Check: report percent agreement, kappa or alpha, and AC1 together.

6. Trusting a high alpha on 20 units too much.

   • Looks like: an alpha of 0.85 on 20 companies presented as settled.
   • Check: report the number of units and a bootstrap confidence interval.

7. Counting an acquired brand twice.

   • Looks like: the parent and its absorbed product both appear as separate logos, which inflates the segment.
   • Check: use the post-deal structure (separate entity versus product versus combined) together with the exit date.

8. Starting from too narrow a universe.

   • Looks like: the long list was seeded from Magic Quadrants, so every logo is an incumbent.
   • Check: analyst gates exclude "Innovative niche providers that are technically leading but still small." Add sources that reach small companies before you grade anything.

A market map is only as good as its oldest unchecked label.

Failures 1, 2, and 4 have the same fix: a dated source for every field and a status window that applies to every row. Failures 5 and 6 have the same fix: report the full set of agreement numbers, not the best one.

How do you keep the map current?

Publish every map with an as-of date and review it at least once a year. Each refresh both removes dead companies and adds new entrants. Churn in the one category with public annual counts has been steady, while the number of new entrants has swung.

Martech is the only category with public whole-landscape counts year over year:

Removals held near 9% a year, while additions fell from 2,489 to 1,488. If you only prune at refresh time, the map ages in one direction, because you never catch new entrants. A naive six-month removal rate, assuming even pacing, would be about 4.3% to 4.5%. That figure is derived and unverified, and no public six-month figure or count of material pivots exists. Measure your own: at each refresh, record how many companies changed status, grade, or segment, and use that rate to set the next review interval.

Re-check the moving parts at each cycle:

• Analyst gates. Gartner's criteria are "rebuilt every cycle," and the SIEM gate went from 200 to 500 customers in one cycle. If you cite an analyst gate as context, re-read the current version.
• Status window. Re-run the status check for every company, not just those that look suspicious. Quiet death is the most common way out.
• Codebook version. Any change to a segment definition means re-running the double-coding check before the next publication.