Positioning and messaging

# Positioning and messaging

## Goal

Turn the current ICP hypothesis, and the market audit when it exists, into one falsifiable market position: who the product is for, what job it is hired to do, what it replaces, why that replacement is worth making now, and which sentences may appear in public language.

Positioning is the choice of comparison. Messaging is the constrained translation of that choice into nouns the buyer already uses. Neither is a tagline contest, a brand workshop, or a page of website copy.

The deliverable is a hypothesis whose allowed external claims are capped by the evidence already in hand. A positioning file is not proof that the product is positioned, differentiated, or understood.

Complete the analysis autonomously. Do not stop to ask clarifying questions. When evidence is missing, make the narrowest assumption that permits useful progress, label it, define the fastest observable test, and state what decision changes if it is false.

Do not modify application code.

## What this prompt is not allowed to become

Do not stack Moore statements, jobs-to-be-done canvases, battlecards, messaging pillars, voice guidelines, and A/B-test ideas as if the pile were a strategy.

Do not invent a new category because existing ones feel crowded.

Do not interview buyers, send outreach, run ads, or treat designed tests as completed validation.

Do not write public claims the current ICP version, implementation, delivery model, or unit economics cannot support.

Do not optimize language so that more people raise their hand. Optimize so the beachhead recognizes itself and adjacent or excluded segments hesitate.

## Prerequisites

This prompt consumes prior GTM artifacts. It does not replace them.

Read, in order:

* all applicable `AGENTS.md` files and repository guidance
* the latest ICP Markdown and YAML pair; prefer `docs/gtm/icp-v1.0.*` over `v0.3`, `v0.3` over `v0.2`, `v0.2` over `v0.1` or `docs/gtm/icp.md`
* `docs/gtm/icp-changelog.md`
* `docs/gtm/market.md` and `docs/gtm/market.yaml` when they exist
* validation-sprint files when they exist
* any existing `docs/gtm/positioning.md`, `docs/gtm/positioning.yaml`, and `docs/gtm/positioning-changelog.md`

Treat YAML as the structured hypothesis and Markdown as the reasoning record. If they conflict, inspect the cited evidence and document the conflict instead of silently choosing one.

If no ICP file exists, execute the codebase-to-ICP prompt in full, then return to this prompt. Do not invent a position on an undescribed customer.

If a market audit exists:

* `DO NOT PURSUE`: do not craft a more attractive position to rescue the market. Produce the diagnosis, name the inherited failure, and stop at `REVISIT ICP` or `HOLD`. Positioning cannot create demand the audit rejected.
* `NARROW OR REPOSITION`: position the narrowed beachhead or revised offer, not the original broad ICP.
* `PURSUE CONDITIONALLY`: position only claims that survive the named gates. Remaining claims stay internal.
* `PURSUE`: still treat the position as a hypothesis. The market decision is not customer comprehension.

If the market audit is absent, treat market size, density, share, and whitespace as `UNKNOWN`. You may still position against the status quo and alternatives named in the ICP. You may not claim category opportunity or an uncontested space.

Position the beachhead, not the widest plausible ICP. Record the primary ICP as a later frame only when the beachhead position does not poison it.

### Evidence ceiling

The ICP version caps what may be said externally:

* `v0.1` (codebase only): internal strategy plus factual product description. No “customers say,” outcome, preference, willingness-to-pay, or category-leadership claims.
* `v0.2` (interviews): customer language, job, trigger, and alternative language are allowed when quoted and sourced. No payment, retention, or leadership claims.
* `v0.3` (paid pilots): observed pilot outcomes may be claimed with sample size, selection bias, and delivery-burden limits attached. No repeatable retention or category ownership.
* `v1.0` (activation, retention, economics): retained outcomes and economic results may be claimed only to the extent the operational evidence supports them.

Use `status: hypothesis` unless buyer behavior has already confirmed that people in the beachhead interpret the product as intended, replace the named alternative, and buy for the claimed reason.

## Inputs

Locate and read, without leaving the repository except for public competitor and category sources:

* product documentation, README, routes, navigation, and UI copy
* onboarding, empty states, and first-run language
* pricing, packaging, and billing copy
* sales decks, one-pagers, outbound sequences, and pitch notes
* interview transcripts, notes, and quoted customer language
* paid-pilot outcomes, win/loss notes, and objection logs
* support and customer-success threads
* analytics that show which pages, features, or offers people actually use
* competitor product pages, pricing pages, docs, and changelogs
* review sites, community posts, and job posts that name the job or the alternatives
* existing blog posts or landing pages that already attempt a position

Search common locations such as `docs/gtm/`, `docs/research/`, `customers/`, `sales/`, `support/`, `marketing/`, and the implemented product.

If an existing positioning file is present, inspect it before editing. Version the new work. Do not silently replace the previous hypothesis.

## Evidence standard

Label every material claim as:

* `REPOSITORY-PROVEN`: Directly established by implementation, documentation, or repository data.
* `MARKET-OBSERVED`: Directly supported by a current external primary source, actual customer behavior, or organization-level evidence.
* `DERIVED`: A reproducible calculation from cited inputs.
* `INFERRED`: Reasonably implied by multiple observations but not directly verified.
* `ASSUMED`: A necessary input without sufficient direct evidence.
* `UNKNOWN`: Cannot currently be estimated responsibly.
* `CONTRADICTED`: Sources conflict, or later evidence broke an earlier claim.

A source proves only what it directly observes.

* Customer language proves what people say. It does not prove they will pay, switch, or stay.
* A competitor page proves how that company describes itself. It does not prove buyers believe it or that it owns the category.
* Implemented behavior proves what can be delivered. It does not prove the buyer wants that delivery.
* Current marketing copy is evidence of the present story. It is not evidence that the story is correct.
* Payment proves purchase. It does not prove the buyer bought for the reason in the draft headline.

For every external source record title, publisher, URL, publication or data date, retrieval date, geography if relevant, the exact sentence used, what it actually proves, and its limits. Do not cite search snippets as evidence.

## Operating defaults

When information is missing:

1. Make the narrowest assumption that still produces a usable position or an explicit `HOLD`.
2. Classify it as `ASSUMED` or `UNKNOWN`.
3. Explain why it is necessary.
4. Define the fastest observable test.
5. State what decision changes if it is false.

Do not invent customer quotes, competitor claims, proof points, category ownership, or willingness to pay.

Do not contact prospects, customers, or competitors.

Public web research is allowed only to quote how alternatives describe themselves and how buyers name the job. Keep that evidence separate from repository evidence.

## Step 1: Inherit the hypothesis

Extract fields. Do not rewrite them as marketing language yet.

From the latest ICP:

* version, status, confidence
* primary ICP and beachhead
* organization type and operating state
* economic buyer, champion, user, approvers
* painful jobs and economic consequences
* triggering events
* current alternatives and existing expenditure
* prerequisites and qualification signals
* initial use case and value metric
* retention and expansion hypotheses
* disqualifiers, YELLOW segments, RED segments
* unknowns and falsification conditions

From the market audit, when present:

* decision and confidence
* selected entry segment
* competitors and status-quo options
* budget sources
* pricing basis or ACV range
* reachability and channels
* most dangerous unknown

From the product:

* what it actually enables today
* required inputs, access, and integrations
* time to first meaningful output
* delivery model and founder or services load
* the current public noun for the product

Produce an inheritance table with one row per field: inherited value, source file, evidence label, implication for positioning. If beachhead and primary disagree, say so. Position the beachhead.

## Step 2: Diagnose the language that already exists

Document, with quotes and sources:

* how the product describes itself on the site, in docs, in the README, and in pitches
* how customers and users describe it, verbatim
* how competitors describe this product, this job, or this category
* the default box a knowledgeable stranger would put the product in after ten seconds
* what the founder or team believes the position is

Name the gaps:

* internal nouns versus buyer nouns
* a category that does not match the delivery model
* features stated as if they were outcomes
* assumed knowledge the beachhead does not have
* language that would attract a YELLOW or RED segment faster than the beachhead
* claims the current evidence ceiling forbids
* a missing alternative: the story never says what this replaces
* a missing exclusion: the story never says who should walk away

This step describes the present story. It does not grant permission to keep it.

## Step 3: Choose one frame, one alternative, and one difference

A position is a choice of comparison. Choose one primary frame. Secondary frames are allowed only when they keep the same noun and the same alternative.

Consider alternatives in this order, and pick the one the beachhead actually uses or pays for:

1. The status quo or workaround, including spreadsheets, docs, and heroics
2. An indirect tool or service hired for the same job
3. A direct product competitor
4. Building in-house
5. Doing nothing and absorbing the cost

The status quo is the default opponent. Do not position against a named vendor the beachhead does not evaluate.

Record, with evidence labels:

* the comparison object: the specific alternative being replaced
* the job being hired
* the budget, time, or risk this product must displace
* the switching or adoption barrier
* the trigger that makes “later” stop being rational
* the reason the alternative is still a reasonable choice
* the honest advantage that alternative keeps

Reject empty contrast. “Unlike spreadsheets,” “unlike legacy tools,” “unlike generic AI,” and “unlike traditional software” are not frames unless the ICP shows that this beachhead uses that thing and loses by using it.

Default to the buyer’s existing name for the job or category. A new category is allowed only when both are true:

* buyers have no working name for the job
* the product cannot be understood as a better way to do a named job

New categories require education spend and behavior change that most early products cannot fund. Buyer language wins.

Then select the smallest difference that is:

* real in the current implementation and delivery model
* tied to a costly job the beachhead already prioritizes
* visible in a short evaluation, or provable without a long relationship
* not a roadmap item
* not a sentence every competitor can publish tomorrow without lying
* survivable at the current price and cost to serve
* specific enough that a non-ICP buyer feels the product is not for them

Reject differences that are feature lists without a causal chain, builder aesthetics, “platform / end-to-end / single source of truth / ease of use / AI-powered,” or advantages that attract RED or YELLOW segments more than the beachhead.

Write the causal chain and label each link:

`job pressure → alternative failure → product action → observable change → valued result`

If any link is `ASSUMED` or `UNKNOWN`, narrow the external claim until the remaining chain holds.

Write one only-we sentence: the sentence that is uniquely true for this product for this buyer. If the primary alternative could publish it tomorrow without becoming false, it is not the sentence. Specificity, constraints, and proof are how a true sentence becomes a unique one.

## Step 4: Split audiences without splitting the product

If the economic buyer, champion, and daily user are different people, write three claim sets from the same position:

* buyer: displaced cost, risk, budget, and decision safety
* champion: implementation burden, political safety, and the proof they can show
* user: the workflow change and the frustration removed

If those three sets imply different products, different alternatives, or different outcomes, the position is incoherent. Rewrite the frame before writing more copy.

Write the exclusion line from RED segments, YELLOW segments, and ICP disqualifiers. A position that cannot repel is not specific.

Run a leakage check: would this language make a RED or YELLOW account raise its hand faster than the beachhead? If yes, the language is too broad or is selling the wrong job. Rewrite it.

Name the retrieval noun: the two to four words a beachhead buyer would use to recommend this product to a colleague. If that noun names the wrong job, the wrong category, or a competitor’s box, the position fails even if the paragraph is elegant.

## Step 5: Write the internal position and three translations

Write the internal statement. This is strategy, not copy:

For [beachhead buyer] at [operating state], after [trigger], who currently [named alternative], [product] is the [retrieval noun] that [only-we difference]. It is not for [exclusion]. Unlike [named alternative], it [observable change], which matters because [valued result]. We can say this now because [evidence at or below the ceiling]. We cannot yet say [forbidden claims].

Then write three external translations that use only claims at or below the evidence ceiling:

1. **One line** for a headline or subject line.
2. **Short paragraph** for a landing-page opening or first-call opener.
3. **Expanded section** for a deck or sales page: job, alternative, difference, proof, why now, and who should walk away.

Rules:

* Use buyer nouns. If a noun does not appear in customer language, product behavior, or a named alternative, do not introduce it.
* State the change for the buyer, not the architecture, unless the architecture is the thing they are buying.
* Be specific enough that the wrong buyer self-selects out.
* Do not use superlatives, unearned “first / only / leading,” or category claims the product has not earned.
* Do not use contrast that only means “we are newer.”

For each translation record:

* the ICP pain, trigger, or job it addresses
* evidence labels on every claim
* the buyer wording and its source
* what would falsify it
* proof readiness
* whether it may be used externally, internally only, or not at all

Produce at most two discarded candidates and the reason each lost. Do not present a menu of equally viable taglines.

## Step 6: Be honest about alternatives and objections

For each realistic alternative, starting with the status quo:

* their actual claim, quoted from a source, or `INFERRED` if you cannot quote it
* where that claim is true
* where it fails for this beachhead
* the advantage they keep
* the advantage this product keeps
* the factual response to their strongest attack
* the response this product must not use because it is false, unproven, or off-ICP

Do not strawman. Do not deny a real advantage. Credible positioning says why this product still wins for this buyer despite that advantage.

Build an objection map from interviews, win/loss notes, support, pilots, and competitor claims. For each objection:

* the objection in the buyer’s words
* class: factual, perceptual, structural, economic, timing, or qualification
* the evidence-backed response, or an admission that it cannot be answered today
* the product, offer, pricing, or ICP change required if it remains unanswerable
* whether this objection is a disqualifier or a response during a real evaluation

Unanswerable objections are limitations. Record them. Do not write external copy that steps around them.

## Step 7: Build the message hierarchy

Do not produce five interchangeable “pillars.” Produce a hierarchy:

* one primary claim
* two to four supporting claims
* explicit anti-claims: sentences this product will not say

For each claim record:

* internal name
* one-sentence claim
* the ICP job, trigger, or alternative it maps to
* evidence labels and proof readiness
* verbatim buyer language with source
* the strongest proof point now available
* the anti-pattern: what this claim must not be stretched into
* allowed surfaces: site, deck, outbound, documentation, support
* forbidden surfaces when proof is `ABSENT` or `UNOBTAINABLE`

The primary claim must survive three attacks:

1. The primary alternative saying the same sentence without lying.
2. A RED or YELLOW buyer reading it as an invitation.
3. A skeptical outsider asking “says who?”

Produce this matrix:

| Claim | Role | Sentence | Evidence | Buyer language | Proof | Readiness | Anti-pattern | External? |
|-------|------|----------|----------|----------------|-------|-----------|--------------|-----------|
| ... | primary / supporting / anti | ... | ... | ... | ... | ... | ... | yes / internal / no |

Then write the narrative sequence. This is the playbook. Every surface uses the same order and may only truncate it:

1. who it is for
2. the job and trigger
3. the alternative being replaced
4. the difference
5. the proof
6. who it is not for
7. the next real commitment: workflow access, a representative case, a pilot, or a paid start, not a slogan

Channels may shorten the sequence. They may not change the noun, the alternative, or the difference.

Attach a short vocabulary list sourced from the same evidence:

* words to use, with source
* words to avoid, and why: wrong audience, unearned claim, competitor-owned noun, or hype
* register for buyer versus user

Do not write a brand-voice essay. If a word cannot be sourced from buyers, the product, or a named alternative, do not add it.

For every key claim define proof:

* type required: data, case, demo, benchmark, quote, third-party validation
* whether it exists
* the strongest proof available now
* what is missing and how to obtain it
* the minimum proof for the current ICP version versus the proof needed to raise the ceiling

Classify proof readiness:

* `PROOFED`: citable evidence exists
* `PARTIAL`: evidence exists but is thin, anecdotal, or off-segment
* `PLANNED`: a specific, resourced activity will obtain it on a dated timeline
* `ABSENT`: no evidence, and no plan
* `UNOBTAINABLE`: cannot be proven ethically or practically

Claims with `ABSENT` or `UNOBTAINABLE` proof must not appear in external messaging. If the only proof is the founder telling the story in the room, the claim fails and must be rewritten or held internal.

## Step 8: Desk-test the position, then design the live tests

Run these desk tests before treating the draft as complete. Record passes, failures, and the revision each failure forced.

1. **Inheritance.** Every external claim traces to the ICP, market audit, or product at or below the evidence ceiling.
2. **Alternative.** A neutral reader can name what this replaces after one reading.
3. **Distinction.** The only-we sentence is not reusable by the primary alternative without becoming false.
4. **Exclusion.** A RED or YELLOW reader would hesitate.
5. **Evidence.** No external claim is `ASSUMED`, `UNKNOWN`, or `CONTRADICTED`. No external claim has `ABSENT` or `UNOBTAINABLE` proof.
6. **Scale.** A new hire can repeat the position from the playbook without the founder.
7. **Leakage.** The language does not optimize for curiosity from the wrong segment.
8. **Economics.** The implied value does not contradict current pricing, delivery cost, or the market ACV range.
9. **Market decision.** The position does not argue with `DO NOT PURSUE` and does not ignore `NARROW OR REPOSITION`.
10. **Noun.** The retrieval noun matches the job the beachhead is hiring, not an internal architecture name.

Failed desk tests require revision. Do not ship a known failing position with a note that someone should fix it later.

Then design live tests. Do not run them. Do not describe them as done.

Include:

* five comprehension questions for people who match the beachhead: what is this, who is it for, what does it replace, why now, why not the alternative
* one landing, outbound, or first-call experiment that would falsify the primary claim
* confirmation and falsification thresholds
* metrics that update confidence: right-buyer conversations, workflow access, paid pilots, win-reason codes, loss-reason codes
* metrics that must not update confidence: compliments, clicks, waitlist signups, generic demo requests, hypothetical willingness to pay
* the review trigger: a new ICP version, a changed market decision, the same objection losing deals repeatedly, or new proof crossing the ceiling

A positioning document that has not met buyer behavior is a strategy memo, not a validated position. Say so in the file.

## Decision

Conclude with one of:

* `POSITION`: the beachhead, alternative, difference, and proof are coherent enough for constrained external use
* `POSITION NARROWLY`: only a named subset of claims may go external; the rest stay internal
* `HOLD`: publish no new external story; the diagnosis and tests are the deliverable
* `REVISIT ICP`: the inherited customer, job, offer, or product cannot support a coherent position

Lead with this sentence:

“As of [date], for [beachhead buyer] in [operating state], [product] should be positioned as [retrieval noun] that [only-we difference], against [named alternative], at evidence ceiling [ICP version and market status], with decision [POSITION / POSITION NARROWLY / HOLD / REVISIT ICP].”

Then explain the decision using the inheritance, the chosen frame, the only-we sentence, the exclusions, the proof gaps, the failed desk tests if any, and the most dangerous unknown.

If the evidence cannot support a public story, return `HOLD` or `REVISIT ICP`. Do not manufacture a confident headline.

## Deliverables

Create or update only these files. If a previous positioning pair exists, keep its content recoverable through the changelog; do not destroy the prior hypothesis without a record.

### 1. `docs/gtm/positioning.md`

Include:

* the lead decision sentence
* source ICP version, market decision, and evidence ceiling
* inheritance table and conflicts
* current-language diagnosis
* chosen frame, named alternative, and why-now trigger
* causal chain and only-we sentence
* retrieval noun
* exclusion line and leakage check
* buyer, champion, and user claim sets when those roles differ
* internal positioning statement
* one-line, paragraph, and expanded translations, with allowed-use flags
* discarded candidates and why they lost
* alternative-honesty cards, status quo first
* objection map, including unanswerable limitations
* message hierarchy and matrix
* narrative sequence
* vocabulary
* proof strategy and readiness
* desk-test results
* designed live tests, explicitly unrun
* open questions and next review trigger

### 2. `docs/gtm/positioning.yaml`

Use a valid machine-readable structure containing:

* `version`
* `status`
* `as_of_date`
* `decision`
* `confidence`
* `source_icp`
* `source_market`
* `evidence_ceiling`
* `beachhead`
* `primary_icp`
* `economic_buyer`
* `champion`
* `users`
* `job`
* `trigger`
* `named_alternative`
* `budget_displaced`
* `category_choice`
* `retrieval_noun`
* `only_we_sentence`
* `exclusion`
* `causal_chain`
* `internal_statement`
* `value_proposition_one_line`
* `value_proposition_paragraph`
* `value_proposition_expanded`
* `external_claims`
* `internal_only_claims`
* `forbidden_claims`
* `audience_claims`
* `alternatives`
* `objections`
* `message_hierarchy`
* `narrative_sequence`
* `vocabulary`
* `proof`
* `desk_tests`
* `live_tests`
* `leakage_risks`
* `assumptions`
* `unknowns`
* `confirmation_conditions`
* `falsification_conditions`
* `sources`

Use `status: hypothesis` unless buyer behavior has confirmed interpretation, replacement, and reason-to-buy. Represent unknown values as `null` with an explanation instead of inventing data.

Version the positioning artifact independently of this prompt. The first hypothesis is `0.1`. Increment when the retrieval noun, named alternative, only-we sentence, exclusion, decision, or allowed external claims change. Do not reuse the prompt version as the artifact version.

### 3. `docs/gtm/positioning-changelog.md`

Append a new entry. Do not edit previous entries.

Record:

* date
* from-version and to-version
* decision then versus now
* what changed in the noun, alternative, only-we sentence, exclusions, or allowed external claims
* why it changed
* supporting evidence
* desk tests that failed and how they were resolved
* questions still unresolved

If this is the first pass, record it as the initial hypothesis and state the inherited ICP and market versions.

After writing, parse the YAML with a real parser and confirm the Markdown, YAML, and changelog tell the same decision, noun, alternative, and evidence ceiling.

## Boundaries

* Do not modify application code.
* Do not overwrite ICP, market, or validation-sprint files.
* Do not invent customers, quotes, proof, demand, or competitor claims.
* Do not contact anyone or describe designed tests as completed.
* Do not treat a completed document as a validated position.
* Do not broaden the ICP to make the story easier.
* Do not position the primary ICP when the beachhead needs a narrower frame.
* Do not create a category to escape a crowded comparison.
* Do not use empty contrast or generic SaaS language.
* Do not claim outcomes, preference, or leadership above the evidence ceiling.
* Do not put `ABSENT` or `UNOBTAINABLE` claims in external messaging.
* Do not strawman alternatives or deny their real advantages.
* Do not write around unanswerable objections.
* Do not produce a pillar workshop, voice essay, or homepage draft as a substitute for the decision.
* Do not change the noun, alternative, or difference across channels.
* Do not argue with a `DO NOT PURSUE` market decision by inventing a prettier story.
* Preserve uncertainty instead of manufacturing confidence.

## Done when

* The latest ICP, and the market audit when present, have been inherited as structured fields rather than restated as copy.
* The evidence ceiling is explicit and every external claim sits at or below it.
* One beachhead, one named alternative, one retrieval noun, and one only-we sentence have been chosen.
* The causal chain is labeled, and broken links forced a narrower claim.
* Exclusions and leakage risks are explicit.
* Buyer, champion, and user claims describe the same product when those roles differ.
* Status quo and other realistic alternatives are treated honestly, with quotes or `INFERRED` labels.
* Unanswerable objections are recorded as limitations.
* The message hierarchy has one primary claim, supporting claims, and anti-claims.
* The narrative sequence is defined and channel-invariant in noun, alternative, and difference.
* Proof readiness is classified, and forbidden claims are out of external messaging.
* All ten desk tests have been run and failures have been resolved or have forced `HOLD` or `REVISIT ICP`.
* Live tests are designed, dated where possible, and explicitly unrun.
* The decision is one of `POSITION`, `POSITION NARROWLY`, `HOLD`, or `REVISIT ICP`.
* All three deliverables exist, parse, and agree with one another.