LMTY

View saved version →

---
name: competitive-asset-audit
description: Audit a body of competitive content - battlecards, sales decks, comparison and alternatives pages, enablement, training, help-center copy - against current evidence, and produce the inventory of claims that are stale, unsupported, contradicted, or newly incomplete, ranked by exposure, with the assets each lives in and the owner or skill that should fix it. Use for "audit our competitive materials", "which claims are stale", "what do we need to update across our battlecards and site", "find competitive claims we can no longer support", and any request whose deliverable is the list of claims and how each one holds up - one page or a whole library, with nothing rewritten. Not for producing the update itself - "update X because Y changed" or "fix the talk track" is competitive-enablement-refresh; a new battlecard is competitive-battlecard; whether the message differentiates is competitive-messaging-audit.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Asset Audit

## Mission

Find every competitive claim the company is currently making that it should not be, across everything that makes one, and say which matter most.

The audit enumerates assets and their material claims, classifies each claim against current evidence, dedupes claims that live in many places, separates claims a market change just broke from claims that were never supported, ranks by exposure, and routes each fix to whoever owns the asset - without rewriting any of it.

## Use this skill when

- someone asks for competitive materials to be audited, scanned, or reviewed for staleness
- a team wants to know which claims across battlecards, decks, and web pages are no longer supportable
- a periodic review of competitive content is due
- a large market change has landed and the question is what, across everything, it touched
- a request bundles the audit with rewrites - do the audit, route the rewrites (Step 8)

## Do not use this skill when

- one change or a defined enablement scope drives the work and the user wants the updated text drafted. Use `competitive-enablement-refresh`.
- one battlecard is the job. Use `competitive-battlecard`.
- the question is whether the messaging differentiates, not whether its claims are supported. Use `competitive-messaging-audit`.
- a rep needs words for one objection now. Use `competitive-objection-response`.
- the artifact is a launch brief or launch enablement and the question is whether its competitive claims hold for the launch. Use `competitive-launch-readiness`.
- prospect-facing comparison copy needs writing - that is not yet in this pack; audit the existing page here and say the rewrite is a separate job.

## Required outcome

For the asset scope in front of the user, answer:

1. Which assets are in scope, and which material competitive claims does each make?
2. For each distinct claim: supported and current, supported but stale, unsupported, contradicted, or unknown - with the evidence?
3. Which claims were always weakly sourced, as opposed to newly broken by a market change?
4. Which claims are duplicated across assets, and where?
5. Ranked by exposure and consequence, which claims need attention first?
6. Which assets are affected by each high-priority claim?
7. Who, or which skill, should fix each?
8. What evidence was used, how fresh is it, and where is coverage missing?

## Context acquisition

Read `references/CONTEXT.md` and `references/INTERNAL.md`.

### Irreducible minimum

- home product
- the asset scope: a repository, a folder, a list of URLs, a set of attached files, or a defined class of assets

Retrieve before asking. When a content repository, CMS, or enablement library is connected, enumerate the assets that mention tracked competitors rather than asking the user to list them. When LMTY is connected, the tracked set defines which competitor names to search for.

If no scope can be established and nothing was supplied, ask one question: what should be audited. Then stop.

### Strongly preferred context

- the content repository or CMS, with asset dates and owners
- current LMTY report, evidence, and change record for every competitor named in the assets
- approved home-product facts: claims, pricing, integrations, security, references
- customer and deal evidence, for assets that make win or objection-frequency claims
- asset usage data, for weighting exposure

## Source priority for this job

1. approved home-product facts for any claim about the home product
2. current LMTY evidence and state for any claim about a competitor
3. deal and customer evidence for any claim about wins, losses, or how often buyers say something
4. the assets themselves, as the thing under audit
5. usage data, for how many people a wrong claim reaches

## Workflow

### Step 1 - Enumerate assets and extract material claims

List every asset in scope with type, location, owner, and last-updated date. From each, pull the material competitive claims: statements about a competitor, about the home product relative to a competitor, about customers switching or choosing, about market position.

Material means a buyer or rep could act on it. "Northwind is where tickets go to wait" is framing; "Northwind's Standard plan is $8 per user" is a claim. Audit claims; note framing only when it rests on a claim.

### Step 2 - Classify each claim by type

Tag each claim: competitor capability, competitor pricing or packaging, competitor customer or market position, home-product capability, home-product pricing, home-product security or compliance, customer reference, win or objection frequency, comparative superlative ("faster", "more", "only"). The type decides which source can verify it.

### Step 3 - Dedupe

Group identical or near-identical claims across assets into one entry with the list of homes. A price that appears in four assets is one claim to verify and four places to fix. Note where the same claim appears with different numbers - that is a finding on its own.

### Step 4 - Retrieve the evidence and mark each claim

For each distinct claim, get the source its type requires and mark:

- **supported and current** - evidence confirms it; wording and date are fine
- **supported but stale** - the fact holds; the wording, figure, or date is behind the current source
- **unsupported** - the source that would verify a claim of this type was available and does not back it; it may be true
- **contradicted** - current evidence says otherwise
- **unknown / insufficient coverage** - the source that would verify it was not available or does not reach it; this is the mark for a home-product claim when no approved facts were supplied, and for a competitor claim the evidence does not cover

Give the source and date for every mark. For competitor claims, absence from the competitor's public material is unknown, not contradicted.

### Step 5 - Separate always-weak from newly broken

For each claim not marked current, say which: was it ever backed by a source, or did a dated change break it? Use the LMTY change record and home-product change history. The two kinds have different owners and different lessons - one is a process gap in how claims get into assets, the other is normal decay.

### Step 6 - Note home-product changes the public data does not show

A home-product change - a feature shipped, a certification obtained, an integration added - can make an asset's claim about the home product stale or make a competitor comparison newly wrong, without anything in the market data moving. Check approved home-product facts against the assets' home-product claims explicitly; do not rely on the competitor record to surface this.

### Step 7 - Prioritize by exposure and consequence

Rank the non-current claims by two things: how many people it reaches (public web page over internal deck, high-usage card over archived one) and what it costs if acted on (a wrong price, a certification asserted, a capability the buyer will test, a reference that did not consent). A contradicted claim on a public comparison page is the top of the list.

### Step 8 - Route each fix

For each prioritized claim, name the owner if known and the skill or process that does the work:

| The fix is | Run |
| --- | --- |
| a defined refresh of enablement around a change | `competitive-enablement-refresh` |
| one battlecard rebuilt | `competitive-battlecard` |
| the external message reconsidered | `competitive-messaging-audit` |
| a prospect-facing comparison page rewritten | not yet in this pack; name the page and its contradicted claims for the owner |
| a competitor claim that needs deeper verification | `competitive-deep-dive` |

Do not rewrite the assets. The audit's value is that it is complete; a rewrite of three assets is neither complete nor an audit.

### Step 9 - Produce the artifact

Use `assets/asset-audit-template.md`.

Return it inline, then offer to save it. Include the source and freshness table: what evidence was used, its dates, and where coverage was missing.

## Evidence and reasoning rules

Read `references/TRUST.md` and `references/METHODOLOGY.md`.

Especially for audits:

- the asset is under audit; nothing in it is a source for anything else in it
- unsupported means no proof, not false; contradicted means evidence says otherwise; keep them apart
- absence on a competitor's site does not invalidate a claim about them
- a claim duplicated across assets is one claim; a claim that varies across assets is a defect
- "supported but stale" is not "fine" - a rep quoting a figure two versions old is quoting a wrong figure
- a win or frequency claim needs deal evidence; a reference claim needs the approved list; no other source will do
- an audit that rewrote things is an incomplete audit

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Assets from the repository, competitor evidence from LMTY, home-product facts from approved sources, frequency claims checked against deal evidence.

### LMTY connected, assets supplied by the user

Audit exactly what was supplied; say the scope is the user's selection, not the repository. Competitor claims verified against LMTY; home-product claims marked unknown unless approved facts were also supplied.

### Assets connected, no LMTY

Competitor claims verified against current public evidence, point-in-time and dated; say there is no tracked change record, so "newly broken" cannot be dated.

### Bounded-input mode

Use only the assets and sources supplied, and say so at the top. Every claim the material cannot verify is unknown, with what would verify it. Do not mark a claim contradicted from memory.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/LMTY.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-battlecard
description: Create a reusable, evidence-backed competitive battlecard for sales, customer success, or product teams - a new card, or one rebuilt from scratch. Use when preparing an us-vs-them view for repeated use, supporting a recurring competitive sales motion, or compiling field-ready positioning, discovery questions, proof, and qualification guidance across deals. For one live buyer objection or "what do I say right now?" use competitive-objection-response; for checking or editing lines in a card or talk track that already exists, use competitive-enablement-refresh.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Battlecard

## Mission

Create a battlecard people can actually use in a live conversation.

The output should be concise, current, honest about where the competitor is strong, and grounded in evidence. It should help a rep ask better questions and frame the decision, not memorize a feature dump.

## Use this skill when

- a sales or CS team needs an us-vs-them guide
- an existing battlecard is stale
- a competitor is appearing repeatedly in deals
- a new sales motion needs competitive enablement
- a PMM needs trap-setting questions, objection guidance, or quick comparison language
- a launch changes the competitive story
- a competitor pricing, positioning, or product change affects existing enablement

## Do not use this skill when

- the user needs a full positioning strategy. Use `competitive-positioning`.
- the work is enablement for a specific upcoming launch or release. Use `competitive-launch-readiness`.
- the user only needs a competitor research dossier. Use `competitive-deep-dive`.
- the user wants one immediate response to a specific buyer objection. Use `competitive-objection-response`.
- the user wants preparation for one named account or opportunity. A battlecard is reusable across deals; use `competitive-deal-prep` for the one in front of them.
- the user wants an existing card or talk track updated after a market change rather than a new card. Use `competitive-enablement-refresh`.
- the user wants every competitive asset scanned for stale claims. Use `competitive-asset-audit`.

## Required outcome

Produce a battlecard that answers:

1. When are we likely to see this competitor?
2. Why do buyers consider them?
3. Where are they genuinely strong?
4. Where do we have a meaningful advantage for the relevant customer?
5. What discovery questions expose fit and trade-offs?
6. What common objections should the field be ready for?
7. What proof supports our response?
8. When are we poorly positioned to win or should we qualify out?
9. What recently changed that makes an older card stale?

## Context acquisition

Read `references/CONTEXT.md`. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- home product
- competitor
- intended audience or sales motion if known

Strongly preferred:
- LMTY current report and recent changes for both subjects
- current positioning and pricing
- win/loss evidence
- sales calls and objection themes
- customer wins and switch stories
- product proof and limitations
- segment, use case, and sales stage

If internal deal evidence is unavailable, do not fabricate why the home company wins or loses.

## Source priority for this job

1. customer/deal evidence for real evaluation criteria, objections, wins, and losses
2. home product truth and approved proof
3. LMTY report and changes for current competitor state
4. competitor primary sources
5. third-party and community evidence for corroboration

## Workflow

### Step 1 - Define the competitive situation

Identify:
- target segment
- use case
- sales motion
- stage of evaluation
- why the competitor appears

If no segment is provided, create a general card and label the missing specificity.

### Step 2 - Establish competitor truth

Summarize:
- what they are
- who they serve
- core promise
- important capabilities
- pricing/packaging when material
- recent changes
- strengths the buyer may legitimately value

Avoid loaded dismissals.

### Step 3 - Establish evaluation criteria

Prefer evidence from calls, win/loss, CRM, and customer research.

Common dimensions:
- outcome fit
- implementation
- ease of use
- depth/breadth
- integrations
- governance/security
- service
- price/value
- time to value
- scalability

Use only dimensions that actually matter for the target situation.

### Step 4 - Build the "why us" position

Select no more than three primary advantages unless the user requests a deep card.

Each advantage should include:
- customer condition where it matters
- evidence
- wording a rep can use naturally

Do not create fake superiority. If the advantage is segment-specific, say so.

### Step 5 - Build trap-setting discovery questions

Questions should reveal customer priorities and trade-offs rather than manipulate the buyer.

Good questions:
- expose a requirement where solutions differ
- reveal future scale or workflow needs
- clarify total cost or operational burden
- surface risks the buyer already cares about

Avoid questions whose answer is obvious or that require the rep to make unsupported competitor claims.

### Step 6 - Build objection handling

For each repeated objection:
- state the objection in buyer language
- diagnose the concern behind it
- provide a short response posture
- suggest a discovery follow-up
- attach proof or an example if available

When internal evidence is missing, keep the response grounded in verified product differences rather than invented win stories.

### Step 7 - Add qualification honesty

Include:
- where the competitor is stronger
- buyer profiles where they may be the better fit
- red flags that make the opportunity hard to win
- what proof is missing

This builds field trust and prevents a battlecard from becoming propaganda.

### Step 8 - Check staleness

Use LMTY changes to identify whether:
- pricing moved
- product capability changed
- positioning changed
- a previously unique home-company claim became parity

Call out exactly which battlecard sections need refresh.

### Step 9 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and". Answer the one this skill owns, in full. For the rest, name the skill that owns it and stop there.

This is not a refusal and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Pricing** - the card leans on a price comparison that is really a monetization question. That is a separate decision: run `competitive-pricing-packaging-review` with this analysis as input.

One line per area the work touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| a market position, messaging, or differentiation | `competitive-positioning` |
| a full profile of one competitor | `competitive-deep-dive` |
| a decision-oriented version for leadership | `competitive-executive-market-brief` |
| launch framing, claims, or enablement for a release | `competitive-launch-readiness` |
| a recurring digest of what changed | `competitive-market-briefing` |
| whether a pattern is a real shift or noise | `competitive-market-shift-analysis` |
| a pricing or packaging decision | `competitive-pricing-packaging-review` |
| a single live buyer objection or "what do I say?" | `competitive-objection-response` |

The failure this prevents is quietly answering the other half yourself. It looks helpful, and it produces a recommendation built on this skill's evidence alone, without the context the other decision actually needs.

### Step 10 - Produce the artifact

Use `assets/battlecard-template.md`.

Default to a concise card. Put detailed evidence in an appendix rather than forcing a rep to scan it live.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for battlecards:
- never invent negative competitor claims
- separate competitor weaknesses from cases where the home product simply fits better
- do not state "we always win because" from one anecdote
- label customer examples by source and representativeness
- use public comparison claims only when supportable and appropriate

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without internal deal evidence:
- produce a market-grounded card
- omit or qualify "why we win", recurring objections, and win examples
- identify the internal sources that would most improve the card

Without LMTY:
- research a current snapshot and state temporal limits

## Composition

Each companion below owns a decision this skill should not make on its own evidence. The hand-off step is where the request's own follow-on question gets named.

Common companions:
- `competitive-positioning`
- `competitive-deep-dive`
- `competitive-launch-readiness`
- `competitive-pricing-packaging-review`
- `competitive-objection-response`

## Quality bar

Read `references/QUALITY.md`.

A strong battlecard should be usable by someone who has two minutes before a call.

It should answer:
- what matters
- what to ask
- how to frame
- what proof to use
- where not to bluff

## Examples of activating requests

- "Build a battlecard for us vs Northwind."
- "Refresh this battlecard using the last 90 days of LMTY changes."
- "Our reps keep hearing that Competitor X has more integrations. Give them a usable response."
- "Create enterprise battlecards for our top three competitors."
- "What parts of our current battlecard are stale?"

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md`
- `references/TRUST.md`
- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/QUALITY.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-deal-prep
description: Prepare an account team for one specific competitive opportunity - the deal state, who they are actually up against, what the buyer said matters in their own words, the three questions that decide the next meeting, proof that fits this account, and the risks and unknowns - from current market truth plus CRM, call, and account context. Use for "prep me for this deal", "we're up against Northwind at Globex", "I have a call with this account tomorrow", "what should the team know before the next meeting", and any request about one named account or opportunity. Not for one live objection on its own, a reusable battlecard, or the design of a formal POC or RFP evaluation.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Deal Prep

## Mission

Get an account team ready for the next meeting on one competitive deal without inventing what the buyer wants, what the competitor has, or how the deal will go.

The output is preparation, not a close plan. It says where the deal stands, who is really in it, what the buyer has actually said matters, what the next meeting has to establish, which proof fits, and where the team is exposed - each line traceable to a call, a record, a market source, or labeled as an assumption.

## Use this skill when

- a rep or PMM asks to be prepared for a named account, opportunity or meeting
- the team is "up against" a named or unnamed competitor in one deal
- someone wants to know what matters before the next call with this account
- a deal has stalled and the team wants to understand the competitive picture in it
- a request bundles deal prep with one objection or a proof ask - take the account, and route the pieces that belong elsewhere (Step 10)

## Do not use this skill when

- the user has one live objection and needs words now. Use `competitive-objection-response`.
- the user wants reusable guidance for many accounts against one competitor. Use `competitive-battlecard`.
- the main job is designing or responding to a formal evaluation - a POC, POV, or RFP with stated criteria. Use `competitive-poc-rfp-plan`.
- the user wants to understand a competitor in general rather than in this deal. Use `competitive-deep-dive`.
- the user wants to know why deals like this are won or lost across many accounts. Use `competitive-win-loss-analysis`.

## Required outcome

For the one account in front of the user, answer:

1. Where does the deal stand, and what is the next event that matters?
2. Which competitors and alternatives are actually in this deal, on what evidence?
3. What has the buyer said they care about, in their words?
4. Which evaluation criteria are confirmed by the buyer, and which are the rep's assumptions?
5. Against those criteria, where is each competitor currently stronger or weaker?
6. What are the three questions the next meeting must answer?
7. What proof fits this account's stated concerns?
8. What are the risks, unknowns, and places the team is poorly positioned?
9. What changed recently on the competitor's side that this account would notice?
10. What should the team do before the meeting?

## Context acquisition

Read `references/CONTEXT.md` and `references/INTERNAL.md`.

### Irreducible minimum

- home product
- the account or opportunity

Retrieve before asking. When LMTY is connected it knows the home product and the tracked competitor set. When opportunity data is connected, the account name is enough to find the record; do not ask the user to paste stage, value or the competitor field.

The competitor is not an irreducible input. Retrieve it from the opportunity's competitor field, the calls, the notes, or the tracked set. If several are active and the request names none, show the observed set with the evidence for each - do not pick one.

If the account cannot be found in any connected source and the user has supplied nothing about it, ask one question: which account, or paste what you have. Then stop.

### Strongly preferred context

- opportunity record: stage, value, segment, stakeholders, competitor fields, next step, dates of last update
- recent calls and meeting notes for this account, with the buyer's wording
- team communication about the account
- current LMTY state, evidence and recent changes for each competitor in the deal
- prior objections raised in this account and whether they were resolved
- approved proof, references and customer examples
- product usage or trial telemetry for this account, when permissioned

## Source priority for this job

1. what the buyer said, from calls and notes, for priorities and criteria
2. the opportunity record for state, stakeholders, and dates - with its last-updated dates
3. approved company proof for what can be claimed
4. current competitor evidence and LMTY state for the competitive picture
5. rep notes and team communication for assumptions and history, labeled as such
6. prior deal outcomes only when they exist and are labeled by representativeness

## Workflow

### Step 1 - Establish the deal state

From the opportunity record and the most recent call or note:

- stage, and when it was last changed
- proposed value and seat count, if recorded
- stakeholders named so far, with roles as recorded
- the next critical event: a meeting, a security review, a procurement deadline, a bake-off
- how current each of those is

State the date of the newest evidence. A record untouched for weeks describes the deal as it was; say so rather than presenting it as today.

### Step 2 - Identify who is actually in the deal

List every competitor or alternative with the evidence that puts it there:

- named by the buyer on a call
- in the opportunity's competitor field, with the date it was set
- mentioned in notes or team channels
- the status quo or "do nothing", when the buyer has said as much

A competitor the rep assumed is in the deal is an assumption. When several are active, keep all of them; when none is evidenced, say the deal's competitive set is unknown and what would establish it.

### Step 3 - Extract buyer priorities in their own words

Pull what the buyer said matters, quoted or closely paraphrased and labeled, with who said it and when.

Keep the buyer's framing. "If we can't get through the security review nothing else matters" is a priority statement; do not translate it into "security is a concern".

Note when different stakeholders said different things.

### Step 4 - Separate confirmed criteria from rep assumptions

Build two lists:

- **Confirmed by the buyer**: a criterion the buyer stated or a requirement they named
- **Assumed by the team**: anything from rep notes, the CRM risk reason, or the user's framing that no buyer statement supports

When the record and the calls disagree - the CRM says price, the call says security review - show the conflict, say which source is stronger for the question, and do not blend them.

### Step 5 - Map competitors to the criteria

For each confirmed criterion, and each competitor in the deal, state from current evidence:

- where the competitor is stronger
- where the home product is stronger, with approved proof
- where neither is established - unknown, not "they don't have it"

Use LMTY evidence with its confidence and date. A capability not observed on a competitor's public site is not a gap. Say what would check it.

### Step 6 - Name the three questions the next meeting must answer

Not discovery questions in general: the three things that, unanswered, leave the team unable to position. Typically:

- which requirement is hard and which is preference
- who decides, and against what
- what the buyer has already concluded about a competitor and from what

Each should change what the team does next.

### Step 7 - Prepare likely objections, only when grounded

Include an objection only if this account raised it, or repeated evidence across a stated number of similar deals shows it. Label which.

For each: the buyer's words, the verified premise, a short posture, and what not to claim. For a full treatment of one objection, hand off to `competitive-objection-response`.

Do not generate a list of objections the competitor "usually" draws from memory.

### Step 8 - Select proof that fits this account

Match approved proof to the confirmed criteria:

- documentation for a stated requirement
- a customer reference in the same segment or with the same concern, only from the approved list
- a measured outcome relevant to a named priority

Name what proof is missing for a confirmed criterion. Do not fill it with a plausible story.

### Step 9 - Risks, unknowns, and where the team is exposed

Be plain:

- requirements the competitor meets and the home product does not, or not yet verified
- stakeholders unmet or unheard
- a stale record, a champion who went quiet, a review not started
- assumptions the plan currently rests on
- anything that suggests the deal may be a poor fit

A prep that has no risks section has not been done.

### Step 10 - Recommend preparation, and hand off the rest

Give a short checklist: what to verify, what to bring, who to involve, what to ask first. Actions, not a guaranteed path to a close.

Route what is not this job:

| The user also wants | Run |
| --- | --- |
| words for one objection right now | `competitive-objection-response` |
| a reusable card for this competitor | `competitive-battlecard` |
| the design of the POC, POV or RFP | `competitive-poc-rfp-plan` |
| a full profile of the competitor | `competitive-deep-dive` |
| why we win or lose deals like this in general | `competitive-win-loss-analysis` |

### Step 11 - Produce the artifact

Use `assets/deal-prep-template.md`.

Return it inline, then offer to save it. Keep account detail to what the team needs; this document travels.

## Evidence and reasoning rules

Read `references/TRUST.md` and `references/METHODOLOGY.md`.

Especially for deal prep:

- the buyer's words outrank the rep's notes for what the buyer wants
- a CRM field is what was recorded, on the date it was recorded
- a competitor is in the deal when evidence puts it there, not when it is the usual suspect
- unknown is a state; write it, and what would resolve it
- one prior deal is one prior deal
- private account data stays in this artifact; it does not become a market claim anywhere else
- a source's interpretation - the rep's risk reason, LMTY's implication sentence, an interviewer's paraphrase - is quoted as that source's

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Deal state from the record, priorities from the calls, competitive picture from LMTY, proof from approved sources.

### LMTY connected, no deal context

The user supplies the account situation. Prepare from what they give and current market state. Label every buyer priority as reported by the user, and say the prep has no independent view of the account.

### Deal context connected, no LMTY

Deal state and priorities from internal sources; competitor facts from current public evidence, point-in-time, with dates. Say there is no tracked history.

### Research mode

Neither connected. Prepare from what the user supplies and public evidence. State that the prep rests entirely on the user's account of the deal.

### Bounded-input mode

Use only the supplied material, and say so at the top. Do not add competitor facts, proof, or deal history from memory. Where the material cannot answer a question the meeting needs, write the question, not a guess.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/LMTY.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-deep-dive
description: Build an evidence-backed, current understanding of a competitor or alternative, including who they serve, positioning, product, pricing, packaging, recent changes, strengths, weaknesses, customer perception, and implications for the home product. Use when a PMM needs to get fully up to speed on one company, prepare a teardown, investigate a new or rising competitor, establish a reusable competitor baseline, or make sense of a move one competitor just made - including what a price, packaging or product change of theirs means, and whether their reasons for it can be known at all.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Deep Dive

## Mission

Create a durable, decision-useful understanding of one competitor or alternative that other PMM skills can reuse.

The deep dive should explain the competitor as a business and customer choice, not merely catalog its website.

## Use this skill when

- a new competitor appears
- a PMM needs a full teardown or briefing on one company
- a competitor becomes strategically important
- a launch, positioning review, battlecard, or pricing analysis needs deeper competitor context
- leadership asks "what do we actually know about them?"
- the team needs a current baseline before tracking future changes

## Do not use this skill when

- the user only wants recent changes across the market. Use `competitive-market-briefing`.
- the user wants an us-vs-them sales artifact. Use `competitive-battlecard` after the deep dive.
- the user wants to know why deals against this competitor are won or lost, from the company's own deal evidence. Use `competitive-win-loss-analysis`.
- the user wants preparation for one account where this competitor is in the deal. Use `competitive-deal-prep`.
- the user wants a broad landscape of many companies. This skill profiles one at a time; for what the market as a whole is doing, use `competitive-market-shift-analysis` or `competitive-executive-market-brief`.

## Required outcome

Produce a deep dive that answers:

1. Who is the competitor and which customers/jobs do they focus on?
2. How do they position the product and company?
3. What do they actually offer?
4. How do they price and package it?
5. What has changed recently and over the available tracked period?
6. Where are they strong?
7. Where are there credible limitations or trade-offs?
8. What do customers/prospects appear to value or dislike?
9. How do they intersect with the home product?
10. What questions should the PMM investigate next?

## Context acquisition

Read `references/CONTEXT.md`. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- competitor identity
- home product identity when implications or comparison are requested

Strongly preferred:
- LMTY competitor object, current report, and changes
- primary competitor website, docs, pricing, release notes, help center
- customer reviews and communities
- sales/win-loss evidence
- analyst or industry context
- home-company product and segment priorities

If the competitor is not yet tracked in LMTY, use current research and clearly label it as a snapshot.

## Source priority for this job

1. competitor primary sources for what they claim and offer
2. LMTY evidence and history for current state and change over time
3. direct customer/deal evidence for buyer perception
4. independent third-party evidence for corroboration
5. community/social evidence for emerging sentiment, clearly labeled
6. speculation only when explicitly requested and labeled

## Workflow

### Step 1 - Establish identity and scope

Confirm:
- company/product
- relevant segment or product line
- whether the task is all-up or specific to a use case

Avoid mixing multiple products from a large company into one vague competitor profile.

### Step 2 - Explain the customer/job

Determine:
- target customer
- important use cases/jobs
- trigger situations
- core promise
- apparent GTM motion

Use customer and deal evidence when available rather than inferring the ICP solely from homepage language.

### Step 3 - Map positioning

Capture:
- category/frame
- headline promise
- value themes
- proof and trust signals
- segment cues
- important messaging changes

Distinguish company positioning from individual product messaging.

### Step 4 - Map product and experience

Focus on meaningful capabilities and workflows.

Capture:
- core product areas
- important differentiating capabilities
- integrations/ecosystem
- onboarding or usage model where observable
- enterprise/security/governance where relevant
- limitations that are actually evidenced

Do not turn this into an exhaustive feature inventory unless the user asks.

### Step 5 - Map pricing and packaging

Capture:
- public pricing
- plan structure
- free/trial motion
- usage limits
- add-ons
- enterprise/custom gates
- recent pricing/packaging changes

Label unknown realized pricing.

### Step 6 - Build the change timeline

When LMTY history exists, summarize the most material observed changes by date.

Look for:
- pricing/packaging
- product launches
- positioning
- target customer
- partnerships/channel
- major proof or customer changes when evidence exists

The timeline is factual. Interpretations belong in a separate section.

### Step 7 - Assess strengths and trade-offs

Strengths should be framed from a buyer's perspective.

Trade-offs may include:
- breadth versus depth
- simplicity versus flexibility
- low entry price versus expansion cost
- integrated suite versus specialist quality
- enterprise depth versus self-serve speed

Do not invent weaknesses from silence or absence of public information.

### Step 8 - Add customer and field reality

When evidence exists, summarize:
- common reasons buyers consider them
- common positive perceptions
- recurring objections or drawbacks
- win/loss themes
- switching stories

Separate repeated patterns from anecdotes.

### Step 9 - Explain intersection with the home product

If a home product is in scope, describe:
- direct overlap
- adjacent overlap
- where customer jobs differ
- where the competitor sets expectations even without direct head-to-head deals
- which changes are most relevant to monitor

Do not force an adversarial framing when the competitor is mostly adjacent.

### Step 10 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and". Answer the one this skill owns, in full. For the rest, name the skill that owns it and stop there.

This is not a refusal and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Enablement** - this profile is being read to arm a sales team. That is a separate decision: run `competitive-battlecard` with this analysis as input.

One line per area the work touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| field talk tracks, objection handling, or a rep-facing card | `competitive-battlecard` |
| a market position, messaging, or differentiation | `competitive-positioning` |
| a decision-oriented version for leadership | `competitive-executive-market-brief` |
| launch framing, claims, or enablement for a release | `competitive-launch-readiness` |
| a recurring digest of what changed | `competitive-market-briefing` |
| whether a pattern is a real shift or noise | `competitive-market-shift-analysis` |
| a pricing or packaging decision | `competitive-pricing-packaging-review` |

The failure this prevents is quietly answering the other half yourself. It looks helpful, and it produces a recommendation built on this skill's evidence alone, without the context the other decision actually needs.

### Step 11 - Produce the artifact

Use `assets/competitive-deep-dive-template.md`.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for deep dives:
- primary source proves the competitor's claim, not customer truth
- do not infer strategy from a single webpage change
- do not treat missing public functionality as proof it does not exist
- label product access limitations
- distinguish company facts from analyst interpretation

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without LMTY:
- use primary-source web research for a point-in-time baseline
- create a dated source table
- omit claims about change over time unless historical evidence exists

Without home-company context:
- deliver the competitor baseline
- omit prescriptive us-vs-them implications

## Composition

Each companion below owns a decision this skill should not make on its own evidence. The hand-off step is where the request's own follow-on question gets named.

This is a foundational skill commonly used by:
- `competitive-positioning`
- `competitive-launch-readiness`
- `competitive-battlecard`
- `competitive-pricing-packaging-review`
- `competitive-market-shift-analysis`
- `competitive-executive-market-brief`

## Quality bar

Read `references/QUALITY.md`.

A strong deep dive should allow another skilled PMM or agent to begin downstream work without repeating basic competitor research.

## Examples of activating requests

- "Get me fully up to speed on Northwind."
- "Build a teardown of Initech for our PMM team."
- "This company just started appearing in deals. Tell me what we know and what we don't."
- "Give me a baseline competitor profile we can track over time."
- "What has materially changed at Competitor X since we started tracking them?"

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md`
- `references/TRUST.md`
- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/QUALITY.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-enablement-refresh
description: Work out what existing competitive sales enablement needs to change now - after a competitor move, a run of field questions, a request from sales, or on a cadence - and draft the update. The deliverable is the changed lines with their proof and date, for a single battlecard, talk track or deck as readily as a set - checks whether sections still hold up, classifies each as current, stale, unsupported or incomplete, prioritizes by what it would cost a rep to say, drafts the smallest useful change, and separates content fixes from distribution problems. Use for "what enablement is stale after this change", "update our talk tracks", "is the Northwind battlecard still accurate", "sales wants this line added - can we say it", "what should sales learn this week". When the deliverable is only the inventory of which claims hold up, with nothing to draft, that is competitive-asset-audit. Not for a new battlecard from scratch or a live objection.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Enablement Refresh

## Mission

Keep what the field says about competitors true, one change at a time.

Given a market change, a pattern of field questions, or a review cadence, find the enablement it touches, say exactly which sections are now stale, unsupported, or incomplete and why, draft the smallest edit that makes them true again, and say separately what has to happen for reps to actually see it.

## Use this skill when

- a competitor change has landed and someone asks what enablement it invalidates
- reps keep asking a question the current assets do not answer
- a PMM wants to refresh the competitive section of a deck, playbook, or training for this week or this quarter
- someone asks what sales should learn from recent market movement
- an existing talk track needs updating rather than rewriting from scratch
- a request bundles the refresh with a broad audit or a new card - take the refresh, route the rest (Step 9)

## Do not use this skill when

- the job is a broad inventory and staleness scan across every competitive asset, with no specific change or scope driving it. Use `competitive-asset-audit`.
- one battlecard is the entire job and it is being written, not refreshed. Use `competitive-battlecard`.
- a rep needs words for one objection now. Use `competitive-objection-response`.
- the user wants to know what changed in the market this week, without an enablement artifact in scope. Use `competitive-market-briefing`.
- the artifact under review is external messaging, not sales enablement. Use `competitive-messaging-audit`.

## Required outcome

For the scope in front of the user, answer:

1. What changed - in the market, in the field, or in the home product - that drives this refresh?
2. Which enablement assets and sections does it touch?
3. For each touched section: current, stale, unsupported, or incomplete - and why, with the evidence?
4. Which changes matter most, by what it would cost a rep to say the old line?
5. What is the smallest update that makes each section true?
6. What proof backs each new line?
7. Where a new line reverses an old one, what does the rep need to know about the history?
8. What can stay as it is?
9. Is the real problem content, or that reps are not seeing the content that exists?

## Context acquisition

Read `references/CONTEXT.md` and `references/INTERNAL.md`.

### Irreducible minimum

- home product
- the enablement scope: which assets, or which change or question set defines them

Retrieve before asking. When LMTY is connected, the change that drives the refresh is usually in its change record. When an enablement repository is connected, find the assets that mention the competitor or claim rather than asking the user to list them.

If neither the scope nor a driving change can be established, ask one question - and offer the likely answer with it, so the user can confirm rather than compose: "I can start with the Northwind talk track and battlecard, since those are the assets the last month's rep questions touched - or name the change or assets you mean." Then stop.

### Strongly preferred context

- LMTY report and change record for the competitors in scope
- the existing enablement: battlecards, talk tracks, decks, playbooks, training modules, with dates
- recent calls and rep questions mentioning the competitors or claims in scope
- asset usage or sales feedback, when available
- approved claims, proof, references, and pricing

## Source priority for this job

1. approved company proof for what any new line may claim
2. current LMTY state and change record for what is true of the competitor now
3. the existing assets, as the thing being verified
4. field questions from calls and channels for what the assets fail to answer
5. asset usage data for whether the problem is content or reach

## Workflow

### Step 1 - Inventory the enablement in scope

List each asset the scope covers: name, type, owner if known, last updated, and the sections that make competitive claims. Pull the claims out as short statements so they can be checked one at a time.

If the same claim appears in several assets, record it once with the list of where it lives.

### Step 2 - Identify the changes that could invalidate it

From the LMTY change record and the home product's own changes over the relevant window: which changes touch a claim in the inventory? Name each change with its date and source, and the claims it bears on.

Include home-product changes. A new integration, a price change, or a certification on the home side invalidates enablement as surely as a competitor move.

### Step 3 - Identify what the field is asking that the assets do not answer

From calls, channels, and rep questions: the recurring questions and objections about these competitors, with counts where possible. Match each against the inventory. A question with no answering section is an incompleteness; a question the section answers wrongly is worse.

### Step 4 - Classify each section

For every section in the inventory:

- **current** - the claim is supported by approved proof or current evidence, and the wording is right
- **stale** - the claim was true and is now out of date: a price that moved, a tier that was removed, a date that passed
- **unsupported** - the claim was never backed by approved proof or evidence; the change did not break it, it was always exposed
- **incomplete** - the section is correct as far as it goes and does not answer what the field is now asked

Give the evidence for each classification. "Stale" without the change that staled it, or "unsupported" without saying what proof is missing, is an opinion.

### Step 5 - Prioritize by field consequence

Order the changes by what happens if a rep says the old line to a buyer today: a wrong price quoted, a capability claimed the buyer will disprove in the demo, a certification asserted that security will deny. Edit volume is not priority. One wrong number in a talk track outranks ten cosmetic updates in a deck.

The order is your judgment. Say so - LMTY reports changes; it does not rank what matters to this team's enablement, and the artifact must not read as if it did.

### Step 6 - Draft the smallest useful update

For each section that needs to change, write the replacement text: the new line, the proof it rests on, and the date. Change only what the evidence requires. Do not rewrite the asset around the update, and do not add claims the refresh was not asked for.

If sales has asked for a line the evidence cannot support, say so and give the supportable version. Do not soften the unsupported claim into a vaguer unsupported claim.

### Step 7 - Preserve history where a claim reverses

When a new line contradicts what the asset said before - "they now publish enterprise pricing" replacing "their enterprise pricing is sales-gated" - note the reversal, the date, and the source. Reps who learned the old line will otherwise reconcile the two by ignoring one.

### Step 8 - Separate content from distribution

Answer separately: is the field asking this because the asset is wrong, or because the right asset exists and nobody opens it? Use usage data if there is any; otherwise say the question is open. A distribution or training problem gets a training note, a channel post, or a session, not another paragraph in a document nobody reads.

### Step 9 - Say what stays, and hand off the rest

List the sections that are current and need no change. That is part of the deliverable - it tells the owner what not to touch.

Route what is not this job:

| The user also wants | Run |
| --- | --- |
| every competitive asset audited, with no driving change | `competitive-asset-audit` |
| a battlecard written from scratch | `competitive-battlecard` |
| a response to one objection now | `competitive-objection-response` |
| the week's market movement on its own | `competitive-market-briefing` |
| the external message reviewed | `competitive-messaging-audit` |

### Step 10 - Produce the artifact

Use `assets/enablement-refresh-template.md`.

Return it inline, then offer to save it or to produce the edited sections as separate snippets ready to paste.

## Evidence and reasoning rules

Read `references/TRUST.md` and `references/METHODOLOGY.md`.

Especially for enablement:

- an existing asset is the thing being verified, never a source
- a change that does not touch any claim in the inventory changes nothing; say so rather than manufacturing an update
- "unsupported" is a classification about proof, not about truth - a true claim with no approved proof is still one a rep cannot safely make
- absence on a competitor's site is not evidence a claim about them is now false
- a new line carries its proof and its date
- a reversal carries its history
- the field asking a question is evidence of a gap; it is not evidence that the answer they want is true

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Changes from LMTY and home-product sources, assets from the repository, field questions from calls, proof from approved claims.

### LMTY connected, no repository or field data

The user supplies the assets. Classify against current market state; say that field questions and usage were not available, so incompleteness and distribution cannot be assessed.

### Repository connected, no LMTY

Classify against current public evidence, point-in-time and dated; say there is no tracked change record, so "stale" rests on the evidence checked today.

### Bounded-input mode

Use only the assets and changes supplied, and say so at the top. Classify against what was supplied. Do not add competitor facts or home-product proof from memory; where a claim cannot be checked against the material, mark it unknown and name what would check it.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/LMTY.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-executive-market-brief
description: Prepare a concise, decision-oriented market and competitive brief for executives, leadership reviews, QBRs, board preparation, strategy discussions, or major planning moments. Use when leadership needs the few market changes, competitor moves, risks, opportunities, and decision questions that matter, with evidence and explicit uncertainty rather than a long CI report.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Executive Market Brief

## Mission

Turn market context into an executive decision surface.

The brief should tell leadership what changed, why it matters to the company's current priorities, what is uncertain, and which decisions or questions deserve attention.

It should not be a compressed competitor newsletter.

## Use this skill when

- preparing for a board or leadership meeting
- creating a QBR competitive section
- briefing a CEO, CMO, CPO, CRO, or product leader
- a strategic planning cycle needs market context
- leadership asks "what changed and what should I care about?"
- a PMM wants to prevent being blindsided in an executive conversation
- a launch, pricing decision, or strategic shift needs executive market context

## Do not use this skill when

- the audience primarily wants operational weekly updates. Use `competitive-market-briefing`.
- the user needs a full competitor teardown. Use `competitive-deep-dive`.
- the user needs a detailed position, pricing, or launch work product. Use the corresponding skill, then summarize here.

## Required outcome

Produce a brief that answers:

1. What materially changed in the relevant period?
2. Which changes matter to current company priorities?
3. What market pattern or strategic implication is worth leadership attention?
4. What is likely noise or not yet decision-relevant?
5. What risks could surprise the company?
6. What opportunities or openings may exist?
7. Which assumptions are weak?
8. What decisions, research, or monitoring should leadership authorize or discuss?

## Context acquisition

Read `references/CONTEXT.md`. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- company/product
- meeting or audience
- relevant time period if different from a sensible default

Strongly preferred:
- company priorities, goals, or strategic motion
- LMTY briefing and significant changes
- current market report
- product roadmap or launch context
- revenue/deal/customer signals
- prior leadership decisions when available

If current company priorities cannot be retrieved, ask only if the answer would materially alter the brief. Otherwise create a market-grounded brief and label the missing internal lens.

## Source priority for this job

1. current company priorities and decision context
2. LMTY significant changes and briefing
3. internal customer, deal, product, and revenue signals
4. current report and competitor evidence
5. external corroboration for material claims

## Workflow

### Step 1 - Identify the executive decision context

Determine:
- audience
- meeting type
- current strategic priorities
- decisions likely to be made
- time horizon

A board brief and a product leadership QBR should select different market facts.

### Step 2 - Gather significant market movement

Use LMTY briefing and change filters when available.

Prioritize:
- pricing/packaging moves affecting economics or buyer expectations
- product launches affecting differentiation or roadmap assumptions
- positioning shifts affecting category narrative
- target-customer movement
- new entrants with actual evidence of relevance
- market patterns supported by multiple signals

### Step 3 - Link market movement to internal reality

When internal sources exist, ask:
- Are these changes appearing in deals?
- Are customers asking for them?
- Do they affect current launches or roadmap?
- Do they affect strategic assumptions?
- Do they alter the company's position or pricing narrative?

This step is what separates an executive brief from a news summary.

### Step 4 - Prioritize by decision consequence

Rank items using:
- potential business impact
- relevance to current priority
- evidence strength
- time sensitivity
- reversibility of a wrong decision

Do not rank by headline size or competitor fame.

### Step 5 - Separate signal from noise

Include a short "not yet worth reacting to" section when the market is noisy.

This is useful executive value, especially when a Slack channel or news cycle is creating anxiety.

### Step 6 - Surface risks and openings

Risks should be specific and evidence-linked.

Openings should be framed as hypotheses or questions unless customer/company evidence makes them stronger.

### Step 7 - Create decision questions

A strong executive brief ends with a small number of questions such as:
- Does this change an assumption behind our current pricing plan?
- Do we need customer research before committing roadmap capacity?
- Should we change launch language because our claimed difference is now parity?
- Is this entrant appearing in enough deals to warrant active tracking?

Avoid generic "keep monitoring" as the only action.

### Step 8 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and". Answer the one this skill owns, in full. For the rest, name the skill that owns it and stop there.

This is not a refusal and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Pricing** - the board question is really whether to change our pricing. That is a separate decision: run `competitive-pricing-packaging-review` with this analysis as input.

One line per area the work touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| field talk tracks, objection handling, or a rep-facing card | `competitive-battlecard` |
| a market position, messaging, or differentiation | `competitive-positioning` |
| a full profile of one competitor | `competitive-deep-dive` |
| launch framing, claims, or enablement for a release | `competitive-launch-readiness` |
| a recurring digest of what changed | `competitive-market-briefing` |
| whether a pattern is a real shift or noise | `competitive-market-shift-analysis` |
| a pricing or packaging decision | `competitive-pricing-packaging-review` |

The failure this prevents is quietly answering the other half yourself. It looks helpful, and it produces a recommendation built on this skill's evidence alone, without the context the other decision actually needs.

### Step 9 - Produce the artifact

Use `assets/executive-brief-template.md`.

Default length:
- one page for leadership/QBR
- up to two pages for board or strategy prep

Put source detail in an appendix.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for executive briefs:
- increase burden of proof as the decision consequence rises
- do not hide contradictions
- label speculative scenarios
- distinguish "competitor moved" from "we need to respond"
- preserve dates and freshness for material claims

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without company priorities:
- produce a market-grounded brief
- replace strong recommendations with decision questions

Without LMTY:
- research a current snapshot and cite collection dates
- avoid implying comprehensive monitored coverage

## Composition

Each companion below owns a decision this skill should not make on its own evidence. The hand-off step is where the request's own follow-on question gets named.

Common inputs from:
- `competitive-market-briefing`
- `competitive-market-shift-analysis`
- `competitive-positioning`
- `competitive-pricing-packaging-review`
- `competitive-launch-readiness`
- `competitive-deep-dive`

## Quality bar

Read `references/QUALITY.md`.

An executive should understand the decision landscape in under five minutes.

Every included item should answer "why is this in front of me?"

## Examples of activating requests

- "Prepare the competitive section for our QBR."
- "I have a board meeting Friday. What market changes could blindside me?"
- "Brief the CPO on what changed this quarter and the roadmap questions it raises."
- "Turn this month's LMTY activity into a CEO-ready one-pager."
- "What should leadership discuss based on the last 90 days of competitor movement?"

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md`
- `references/TRUST.md`
- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/QUALITY.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-launch-readiness
description: Prepare, pressure-test, or refresh a product or feature launch against current competitors, alternatives, market expectations, pricing, positioning, and recent market changes. Use when planning a launch, reviewing a launch brief, creating competitive launch guidance, preparing enablement, asking how a new release should be framed relative to the market, or judging whether a capability is parity, catch-up, or real differentiation.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Launch Readiness

## Mission

Help a PMM launch with an accurate picture of the market and a clear view of where the release is differentiated, expected, vulnerable, or likely to create confusion.

The skill should make the launch team better prepared without turning competitor behavior into product strategy by default.

## Use this skill when

- a product or feature launch is being planned or reviewed
- a PMM needs a competitive section for a launch brief or enablement
- a team wants to know how a release compares with current alternatives
- a launch needs pricing, packaging, positioning, or feature context
- a competitor has recently shipped something that may affect launch framing
- leadership asks whether the launch is meaningfully differentiated
- a PMM wants a final competitive readiness check before launch

## Do not use this skill when

- the user only wants a broad competitor profile with no launch decision. Use `competitive-deep-dive`.
- the user primarily wants a new positioning strategy. Use `competitive-positioning`.
- the user primarily wants a pricing decision. Use `competitive-pricing-packaging-review`.
- there is no launch, release, or product change to evaluate.
- the question is what product should build or investigate, rather than how to frame something already being shipped. Use `competitive-roadmap-review`.
- the artifact under review is the company's standing messaging, not launch framing. Use `competitive-messaging-audit`.

## Required outcome

Produce a launch-ready competitive assessment that answers:

1. What is the release and who is it for?
2. What customer expectation or job does it address?
3. Which competitors or alternatives matter for this release specifically?
4. What is table stakes, differentiated, behind, or ambiguous?
5. What changed recently that should alter the launch plan or language?
6. What claims can the team make confidently?
7. What should sales, product, marketing, and leadership be prepared for?
8. What important unknowns remain?

## Context acquisition

Read `references/CONTEXT.md` and follow it. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- release or feature description, spec, PRD, or launch brief
- home product identity
- relevant competitor set or permission to identify it

Strongly preferred context:
- target segment and use case
- launch goals
- current positioning and messaging
- current pricing or packaging if relevant
- LMTY report and changes
- customer calls, win/loss, research, or sales objections
- current roadmap or strategic motion

When LMTY is connected, retrieve only the report sections and changes relevant to this release. Do not dump the entire tracked market into context.

## Source priority for this job

1. release spec and product truth
2. LMTY current report and tracked changes
3. direct competitor product documentation, pricing, and launch sources
4. customer or deal evidence about the problem and alternatives
5. company positioning and strategy
6. third-party or community sources for corroboration and perception

## Workflow

### Step 1 - Define the launch claim

Translate the release into a simple statement:
- what changed in the product
- who can use it
- what job it improves
- what the company appears to want customers to believe

If the release brief contains multiple unrelated capabilities, separate them before comparing.

### Step 2 - Identify the competitive decision set

Do not compare against every tracked competitor automatically.

Choose the competitors and alternatives that matter because they:
- solve the same job
- appear in the same deals
- set customer expectations
- are strategically important for the target segment
- recently changed in a way relevant to the release

Explain why each included competitor matters.

### Step 3 - Establish current market state

For the relevant dimensions, determine:
- what each subject offers now
- how each subject describes it
- pricing or packaging if material
- availability and maturity where known
- proof or evidence
- freshness and coverage

Prefer job-relevant comparison dimensions over feature-count tables.

### Step 4 - Inspect recent movement

Look for relevant changes over the most useful period, normally 90 days unless the launch cycle or market pace suggests another window.

Ask:
- Did a competitor recently ship the same capability?
- Did packaging or pricing alter the perceived value?
- Did positioning change in a way that affects our launch language?
- Is an adjacent player creating a new customer expectation?

Separate observed changes from interpretations of their significance.

### Step 5 - Classify launch posture

For each meaningful dimension, classify the release as one of:
- **Category expectation** - customers increasingly expect this
- **Parity** - materially comparable to established alternatives
- **Differentiated** - a meaningful difference exists and matters to the target customer
- **Catch-up** - closes a known gap but should not be marketed as category-defining
- **Unproven** - the claimed advantage lacks enough customer or market evidence
- **Vulnerable** - the launch creates an obvious objection or comparison risk

Do not force every dimension into a positive frame.

### Step 6 - Build the launch narrative implications

Determine:
- which claims are safe and supportable
- which claims are weak or generic
- which competitor comparisons should be avoided
- what customer problem should lead the story
- whether the release changes the company's broader competitive position

Do not invent a new positioning strategy unless needed. Flag when the launch exposes a positioning problem and recommend `competitive-positioning` as the next job.

### Step 7 - Prepare cross-functional guidance

Produce concise guidance for the teams that need it.

Typical guidance:
- Product - unresolved gaps or questions worth validating
- Sales - expected objections and the evidence-backed response posture
- Customer Success - migration, adoption, or expectation questions
- Marketing - claims, proof, comparison angles, content needs
- Leadership - what is strategically notable and what is not

### Step 8 - Identify readiness gaps

List only gaps that could materially hurt the launch, such as:
- unsupported differentiation claim
- stale competitive assumption
- pricing conflict
- missing proof
- unclear target segment
- known competitor strength with no response
- customer expectation not reflected in the release

### Step 9 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and". Answer the one this skill owns, in full. For the rest, name the skill that owns it and stop there.

This is not a refusal and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Pricing** - the competitor bundled this capability into their base plan. That is a separate decision: run `competitive-pricing-packaging-review` with this analysis as input.

One line per area the work touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| field talk tracks, objection handling, or a rep-facing card | `competitive-battlecard` |
| a market position, messaging, or differentiation | `competitive-positioning` |
| a full profile of one competitor | `competitive-deep-dive` |
| a decision-oriented version for leadership | `competitive-executive-market-brief` |
| a recurring digest of what changed | `competitive-market-briefing` |
| whether a pattern is a real shift or noise | `competitive-market-shift-analysis` |
| a pricing or packaging decision | `competitive-pricing-packaging-review` |

The failure this prevents is quietly answering the other half yourself. It looks helpful, and it produces a recommendation built on this skill's evidence alone, without the context the other decision actually needs.

### Step 10 - Produce the artifact

Use `assets/launch-readiness-template.md` unless the user asks for another format.

## Evidence and reasoning rules

Read `references/TRUST.md` and follow it.

Especially for launches:
- competitor existence is not evidence of customer demand
- a feature match is not proof of parity in experience or outcome
- a recent competitor launch is not automatically a reason to change the roadmap
- do not infer competitor motive
- do not label something a differentiator unless the difference is both real and relevant to the target customer

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without LMTY:
- perform a current snapshot using available primary sources if web access exists
- clearly say that the analysis does not establish longitudinal change unless historical evidence is available
- ask the user to supply internal customer/deal context only when it would materially alter the launch posture

With no external research:
- pressure-test only against supplied materials
- label the market assessment as bounded to those materials

## Composition

Each companion below owns a decision this skill should not make on its own evidence. The hand-off step is where the request's own follow-on question gets named.

This skill commonly composes with:
- `competitive-deep-dive` for a new or poorly understood competitor
- `competitive-market-shift-analysis` when the launch is responding to a broader change
- `competitive-positioning` when the release changes the value story
- `competitive-pricing-packaging-review` when monetization is part of launch readiness
- `competitive-battlecard` to turn the launch assessment into field enablement
- `competitive-executive-market-brief` for launch reviews with leadership

## Quality bar

Read `references/QUALITY.md`.

A strong result should make a PMM comfortable answering, in one meeting:
- why this launch matters now
- where it really stands relative to alternatives
- what the team should and should not claim
- which objections are predictable
- what still needs proof

## Examples of activating requests

- "Pressure-test this launch against our competitors."
- "Here is the PRD. What do I need to know competitively before we launch?"
- "Build the competitive section of my launch brief."
- "Northwind just shipped something similar. Does that change how we should launch this?"
- "Tell me whether this is parity, catch-up, or real differentiation."

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md` for detailed launch analysis guidance
- `references/TRUST.md` for evidence rules
- `references/CONTEXT.md` for context acquisition
- `references/DEGRADATION.md`
- `references/INTERNAL.md` for fallback behavior
- `references/QUALITY.md` for output standards

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-market-briefing
description: Turn recent competitor and category movement into a calm, prioritized PMM briefing with what changed, why it may matter, evidence, freshness, and follow-up questions. Use for weekly or monthly market updates, Slack or email briefings, recurring competitive reviews, or whenever a team needs a high-signal summary of recent movement without a raw alert stream.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Market Briefing

## Mission

Create the recurring market briefing a PMM will actually read and share.

The briefing should compress recent movement, preserve evidence and freshness, and make clear what deserves attention without turning every change into a strategic recommendation.

## Use this skill when

- preparing a weekly or monthly competitive briefing
- summarizing recent market movement for a PMM or team
- converting tracked competitor changes into an audience-specific update
- a Slack channel is noisy and the team needs a calm digest
- a PMM wants "what changed since last time?"
- a recurring review needs continuity rather than fresh research from scratch

## Do not use this skill when

- the user asks whether a pattern is a real market shift. Use `competitive-market-shift-analysis`.
- the user wants an executive decision brief. Use `competitive-executive-market-brief`.
- the user wants deep analysis of one competitor. Use `competitive-deep-dive`.
- the user wants the week's changes turned into updated sales enablement. Use `competitive-enablement-refresh`.

## Required outcome

Produce a briefing that answers:

1. What materially changed in the requested period?
2. Which changes deserve attention and which are routine?
3. What is interpretation - yours - versus the observed fact?
4. What is the evidence and freshness?
5. Which competitor or category should the team look at next?
6. What changed relative to prior context, not merely what exists today?
7. What should be watched without overreacting?

## Context acquisition

Read `references/CONTEXT.md`. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- home product or market
- desired period if not obvious

Strongly preferred:
- LMTY changes covering the period, filtered by date after retrieval
- current report for orientation
- audience or team priorities
- prior briefing if continuity or follow-up matters

Default period:
- weekly briefing: last 7 days
- monthly briefing: last 30 days
- LMTY returns changes newest-first with a limit, not a date filter: retrieve enough to cover the window, then filter by observed date and state the window you actually covered

Do not silently substitute the 90-day What's Changed default for a weekly digest.

## Source priority for this job

1. LMTY change records for observed facts
2. LMTY report for current-state orientation
3. primary sources/evidence tied to material changes
4. internal context only when tailoring relevance to a team or priority

When LMTY is unavailable, reconstruct a dated briefing from current research and state that monitoring coverage may be incomplete.

## Workflow

### Step 1 - Establish period, audience, and coverage

State:
- period covered
- as-of date
- tracked product/competitor scope
- any important coverage limitations

The reader should never confuse a filtered window with the entire market.

### Step 2 - Gather recent observed changes

Collect changes in the requested period.

Prefer meaningful movement over first-capture noise.

Group by:
- pricing/packaging
- product/releases
- positioning/messaging
- target customer / GTM
- other material category movement

Do not force a section if nothing important happened.

### Step 3 - Rank, and own the ranking

LMTY records what changed. It does not tell you what mattered: there is no ranked briefing object to borrow. The ordering in this briefing is the skill's own judgment and must be presented as such.

Rank using these criteria, and name the ones that decided the top items:
- relevance to the home product
- magnitude
- novelty
- time sensitivity
- evidence quality

Preserve the distinction the reader needs:
- the change record is the observed fact, with its date and evidence
- the ranking, and every "why it may matter", is interpretation

Say so explicitly - one line is enough: "Ordered by relevance to us and magnitude; this is my read, not a scored output." Never attribute the ordering to LMTY.

### Step 4 - Compress repeated movement

If several small changes tell one coherent story, summarize the pattern and list the supporting observations underneath.

Do not inflate significance by counting correlated updates as independent signals.

### Step 5 - Add practical relevance

For each top item, provide a restrained "why it may matter" that is appropriate to the available context.

If internal strategy is unknown, phrase as:
- question worth checking
- possible implication
- area to monitor

rather than a company-specific prescription.

### Step 6 - Create the watchlist

Include a small number of items that are:
- interesting but not yet significant
- researching / incomplete
- early signs worth revisiting

This lets the briefing preserve weak signals without mixing them into the top-line story.

### Step 7 - Preserve continuity

When prior briefing or history exists, note:
- continued pattern
- escalation
- reversal
- newly confirmed signal
- issue that dropped in importance

This is one of the biggest advantages of LMTY over ad hoc research.

### Step 8 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and". Answer the one this skill owns, in full. For the rest, name the skill that owns it and stop there.

This is not a refusal and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Deep dive** - one competitor now warrants more than a line in a digest. That is a separate decision: run `competitive-deep-dive` with this analysis as input.

One line per area the work touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| field talk tracks, objection handling, or a rep-facing card | `competitive-battlecard` |
| a market position, messaging, or differentiation | `competitive-positioning` |
| a full profile of one competitor | `competitive-deep-dive` |
| a decision-oriented version for leadership | `competitive-executive-market-brief` |
| launch framing, claims, or enablement for a release | `competitive-launch-readiness` |
| whether a pattern is a real shift or noise | `competitive-market-shift-analysis` |
| a pricing or packaging decision | `competitive-pricing-packaging-review` |

The failure this prevents is quietly answering the other half yourself. It looks helpful, and it produces a recommendation built on this skill's evidence alone, without the context the other decision actually needs.

### Step 9 - Produce the artifact

Use `assets/competitive-market-briefing-template.md`. For a filled-out fictional example of the intended quality, structure, and specificity, read `assets/competitive-market-briefing-example.md`.

Default to a concise briefing that fits comfortably in Slack or email. Offer a deeper appendix only when needed.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for briefings:
- every material change needs an observed date
- "why it matters" must be clearly interpretive
- avoid unsupported competitor motives
- do not turn a no-change result into a claim of stability when coverage is partial
- surface lapsed/frozen/researching status explicitly

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without LMTY:
- create a dated research snapshot
- explicitly say the briefing may miss changes outside the sources inspected
- do not claim comprehensive continuity

With LMTY but no company context:
- preserve strong market summary
- keep implications conditional

## Composition

Each companion below owns a decision this skill should not make on its own evidence. The hand-off step is where the request's own follow-on question gets named.

This skill is often the entry point for:
- `competitive-market-shift-analysis` when several items form a pattern
- `competitive-deep-dive` when one player becomes important
- `competitive-pricing-packaging-review` when pricing changes matter
- `competitive-positioning` when messaging movement affects the home position
- `competitive-launch-readiness` when a change intersects an upcoming release
- `competitive-executive-market-brief` when leadership needs a decision-oriented version

## Quality bar

Read `references/QUALITY.md`.

A strong briefing should create calm and shared awareness.

The reader should know:
- what happened
- what deserves attention
- what is interpretation
- what remains uncertain
- where to go deeper

## Examples of activating requests

- "Give me this week's competitive briefing."
- "What changed across our competitors in August?"
- "Turn LMTY's latest changes into a Slack-ready PMM update."
- "What mattered this month and what should we keep watching?"
- "Summarize what changed since our last QBR without redoing the research."

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md`
- `references/TRUST.md`
- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/QUALITY.md`

Referenced files: 9 — file references are metadata, not package contents.

View saved version →

---
name: competitive-market-shift-analysis
description: Determine whether a pattern of competitor, category, technology, buyer, pricing, or positioning signals represents noise, an isolated move, an emerging market shift, or an established change in expectations. Use when a PMM asks what a cluster of changes means, whether a trend is real, how much attention it deserves, or what evidence should trigger a response.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Market Shift Analysis

## Mission

Help a PMM distinguish meaningful market movement from the constant stream of competitive noise.

The output should improve orientation under uncertainty. It should not pretend to predict the future with certainty.

## Use this skill when

- multiple competitors appear to be moving in the same direction
- a new technology or behavior may be changing category expectations
- a PMM asks whether something is a real trend or just noise
- leadership is reacting to scattered competitor announcements
- a new entrant or adjacent player may be changing the market
- a team wants to know what signals deserve monitoring
- a PMM is early to a shift and does not know what it will lead to

## Do not use this skill when

- the user only wants what changed. Use `competitive-market-briefing`.
- the user wants a deep profile on one company. Use `competitive-deep-dive`.
- the user wants positioning implications as the primary output. Use `competitive-positioning` after establishing the shift.
- the question is what a change means for a specific upcoming launch. Use `competitive-launch-readiness`.
- the shift is established and the question is what product should investigate because of it. Use `competitive-roadmap-review`.

## Required outcome

Produce an analysis that answers:

1. What signals are we observing?
2. Which are independent versus copies or reactions to the same event?
3. What customer or buyer evidence supports the pattern?
4. Is this isolated noise, an emerging shift, an accelerating shift, or an established expectation?
5. What would falsify the current interpretation?
6. Which areas - product, positioning, pricing, GTM, enablement - does the shift raise a question for, and which skill owns answering it?
7. What should the team monitor next?
8. What should the team avoid overreacting to?

## Context acquisition

Read `references/CONTEXT.md`. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- the suspected shift or set of signals
- market/product context

Strongly preferred:
- LMTY changes across the tracked set
- LMTY current report and briefings
- customer calls, reviews, surveys, or win/loss
- adjacent-market evidence
- analyst or ecosystem data when relevant
- search, social, community, or usage signals when available
- company strategy and roadmap if implications are requested

## Source priority for this job

A shift is stronger when evidence spans different source types.

Prefer a portfolio of:
- observed competitor behavior
- customer/buyer behavior
- category or ecosystem behavior
- economic or regulatory drivers when relevant
- internal deal/product evidence

Several competitors repeating the same marketing phrase is not automatically independent evidence.

## Workflow

### Step 1 - State the hypothesis neutrally

Do this first, always, and put it in the output. Most requests arrive as a mood rather than a claim - "everyone is adding AI", "should we be worried about X" - and a mood cannot be tested. Nothing in the later steps works until the question has an answerable shape.

Convert the user's concern into a single falsifiable statement, and say what would count as evidence against it.

| Arrives as | Restate as |
| --- | --- |
| "Everyone is adding AI." | "AI features are becoming a baseline expectation in this category, such that buyers now screen for them." |
| "Is usage-based pricing taking over?" | "Usage-based pricing is displacing per-seat as the default in this category." |
| "Are we behind on integrations?" | "Integration breadth has become a primary evaluation criterion for our buyers." |

**Say that the restatement is yours.** Turning "something feels off" into a testable claim is interpretation, and it inherits the same rule as any other interpretation in this pack: label it. One line, before the analysis:

> I've read your concern as: *"buyers in this category increasingly expect consolidated platforms over point solutions."* That framing is mine, not your words - say so if it is the wrong question and I will re-run against the right one.

Then proceed on it. Do not wait for confirmation: a labeled inference the user can correct is more useful than a question they have to answer before getting anything. Only stop and ask when the request names no market, no subject and no observation at all, so there is nothing to restate.

### Step 2 - Build the signal ledger

For each signal record:
- source
- date
- subject
- observed fact
- signal type
- relevance
- independence
- evidence quality

Signal types may include:
- product
- pricing/packaging
- positioning/messaging
- buyer behavior
- customer request
- deal behavior
- capital/investment
- hiring
- partnership/channel
- regulation
- community/reputation

### Step 3 - Remove correlated noise

Identify signals that are not independent.

Examples:
- five articles reporting one vendor announcement are one underlying signal
- three competitors using the same AI vocabulary may reflect broad hype rather than buyer demand
- one analyst report repeated in social posts is not multiple confirmations

### Step 4 - Look for buyer-side confirmation

Ask whether customers are:
- requesting the capability
- changing evaluation criteria
- switching products
- changing willingness to pay
- adopting new workflows
- asking new objections
- using adjacent tools to solve the job

Buyer-side evidence often determines whether competitor activity is merely supply-side experimentation or a real demand-side shift.

### Step 5 - Classify shift maturity

Use one of five states:

- **Noise** - insufficient coherent evidence
- **Isolated move** - meaningful for one player but not a market pattern
- **Emerging shift** - multiple credible signals, buyer impact still uncertain
- **Accelerating shift** - independent supply and demand signals are reinforcing
- **Established expectation** - customers increasingly treat the change as normal or table stakes

State confidence and evidence gaps.

**Start at noise and make the evidence earn each step up.** The default answer to "is this a real shift?" is "not yet demonstrated", because that is what thin evidence supports and because the cost of the two errors is not symmetric: calling noise a shift starts roadmap arguments and burns credibility, while calling an early shift noise costs one monitoring cycle.

Each level has a bar. Do not award a level whose bar the evidence does not clear:

| To claim | You need |
| --- | --- |
| Isolated move | One credible, dated signal about one player |
| Emerging shift | Signals from **independent** subjects, not one event reported repeatedly, and at least one that is not a vendor announcement |
| Accelerating shift | Independent supply-side signals **plus** buyer-side evidence - questions asked, requirements written, deals lost |
| Established expectation | Buyer-side evidence that the capability is screened for rather than asked about |

Three vendor announcements in one quarter is supply-side coherence with no demand evidence: that is an emerging shift at most, never an accelerating one. Say plainly which bar was not met and what evidence would clear it.

**Independence is necessary, not sufficient.** Two signals can be independent of each other and both still be weak. Before awarding a level, check what each signal actually is:

| Evidence | Weight |
| --- | --- |
| The subject's own pricing page, changelog, docs, filing | Primary. Full weight. |
| A tracked change record with a source and an observed date | Primary. Full weight. |
| Third-party description of what a vendor did - blog post, article, roundup | Second-hand. Supports "something may have happened", not "this is what happened". |
| Opinion or speculation about where the category is going | Not evidence of a shift. Evidence that someone is talking about one. |
| Recollection, "I think I saw", conference hearsay | Not evidence. Record it as a question to verify. |

**Cap the classification at the weakest link.** A level needs signals that actually clear its bar, not signals that would clear it if verified:

- if every signal for a subject is second-hand, that subject supports **at most** an isolated move, however many outlets carried it
- in bounded-input mode, or where nothing can be verified, cap at **isolated move** unless the supplied material includes primary sources
- two second-hand descriptions plus one customer question is not an emerging shift. It is an isolated move with a clear next step: verify the two vendors' primary sources and ask the other customers.

Under-classifying costs a monitoring cycle. Over-classifying sends a roadmap conversation after a blog post.

### Step 6 - Explain the mechanism

Describe what may be changing in customer progress or market structure.

Possible mechanisms:
- cost or speed threshold changed
- new technology removed friction
- buyer expectation shifted
- distribution changed
- regulation changed requirements
- new pricing model changed adoption
- adjacent category entered the job

Do not infer competitor motives.

### Step 7 - Map implications by time horizon

Separate:
- now - immediate awareness, claims, enablement, launch risk
- next - experiments, research, roadmap questions
- later - structural position, category, moat, business-model questions

Do not recommend large irreversible moves from early-stage evidence without internal context.

An implication names a decision that is now worth making. It does not make it. "This raises whether our positioning should lead on governance" is an implication; two paragraphs of recommended messaging is a positioning artifact, and this skill does not produce one.

### Step 8 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and": *is this a real shift, and what should our positioning be?* Answer the first in full. For the second, name the skill that owns it and stop.

This is not a refusal, and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Positioning** - this raises whether we should lead on usage-based value framing. That is a positioning decision, not a shift question: run `competitive-positioning` with this analysis as input.

One line per area the analysis touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| a market position, messaging, or differentiation | `competitive-positioning` |
| a pricing or packaging decision | `competitive-pricing-packaging-review` |
| launch framing, claims, or enablement for a release | `competitive-launch-readiness` |
| field talk tracks, objections, or a rep-facing card | `competitive-battlecard` |
| a full profile of one of the competitors involved | `competitive-deep-dive` |
| a version for leadership | `competitive-executive-market-brief` |

The failure this prevents: silently answering the positioning half yourself. It looks helpful, and it produces a positioning recommendation built on shift evidence alone, without the customer, product and company context that a positioning decision needs.

### Step 9 - Define the monitoring plan

Specify:
- signals that would strengthen the thesis
- signals that would weaken it
- subjects or sources to watch
- useful review window

When LMTY is connected, translate this into filters/sections that can be queried repeatedly.

### Step 10 - Produce the artifact

Use `assets/market-shift-template.md`.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for shifts:
- distinguish signal count from independent evidence
- distinguish supply-side activity from customer demand
- do not use confident trend language from a single company move
- name falsifying evidence
- prediction is allowed only as clearly labeled scenario or speculation

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without LMTY:
- research current and dated historical sources where possible
- be explicit when the time series is incomplete

Without buyer evidence:
- classify supply-side movement separately
- avoid calling the shift established

## Composition

This skill establishes whether something is happening. It does not decide what to do about it: each companion below owns a decision that would be wrong to make from shift evidence alone. Step 8 is where the request's own follow-on question gets named.

Common companions:
- `competitive-market-briefing`
- `competitive-deep-dive`
- `competitive-positioning`
- `competitive-launch-readiness`
- `competitive-pricing-packaging-review`
- `competitive-executive-market-brief`

## Quality bar

Read `references/QUALITY.md`.

A strong result should calm reactive teams by showing:
- which facts matter
- how much evidence exists
- what is still uncertain
- what would change the conclusion
- which responses are proportionate to the evidence

## Examples of activating requests

- "Everyone is adding AI. Is this actually a market shift or just noise?"
- "Three competitors changed packaging. What is happening?"
- "Are we seeing a real move upmarket in this category?"
- "What would have to happen before we treat this as table stakes?"
- "Analyze the last 90 days of changes and tell me which patterns are real."

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md`
- `references/TRUST.md`
- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/QUALITY.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-messaging-audit
description: Pressure-test current messaging - a homepage, a message hierarchy, a pitch, a product page, campaign copy - against the company's positioning, the words customers actually use, what competitors now say, and recent market movement. Says what still works, what has become generic because competitors converged on it, where the language does not match how buyers talk, which claims are true but unproven or differentiated but irrelevant, and which questions are really positioning decisions. Use for "review our messaging", "does this homepage still differentiate us", "competitors started saying the same thing - what broke", "pressure-test this message hierarchy against customer language". Not for re-deciding the underlying position, writing prospect-facing comparison copy, or launch-specific framing.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Messaging Audit

## Mission

Tell a team whether the words they are using still do the job - given what they decided to stand for, what customers say they want, what competitors have started saying, and what moved in the market - without re-deciding the position underneath.

The review diagnoses the hierarchy, tests each material claim against competitor language and customer vocabulary, sorts claims into still-differentiating, now-generic, unproven, and irrelevant, recommends changes with the evidence and confidence for each, and separates the questions that are about words from the ones that are about strategy.

## Use this skill when

- someone asks for messaging, a homepage, a pitch, or a message hierarchy to be reviewed or pressure-tested
- competitors have started saying what the home product says and the team wants to know what that broke
- a team suspects the message no longer matches how customers describe the problem
- campaign or page copy needs checking against positioning before it ships
- a request bundles the review with a repositioning or a launch message - review the message, route the rest (Step 9)

## Do not use this skill when

- the position itself is in question - who the product is for, against what alternative, on what basis. Use `competitive-positioning`.
- the copy is prospect-facing competitor comparison - "us vs them" pages or sendable comparison documents. That is not yet in this pack; review the page's claims here and say the copy is a separate job.
- the framing is for one launch. Use `competitive-launch-readiness`.
- the artifacts are internal sales enablement, not external messaging. Use `competitive-enablement-refresh`.
- the question is whether specific claims across many assets are still supported by evidence, rather than whether the message differentiates. Use `competitive-asset-audit`.
- the user wants messaging written and has no current messaging to review. Ask for the current message, or point to `competitive-positioning` if there is no position yet.

## Required outcome

For the message set in front of the user, answer:

1. What is the hierarchy - category, value, differentiation, proof, call to action - and who is it for?
2. Which claims still differentiate, against what competitors now say?
3. Which have become generic, and when did the convergence happen?
4. Where does the language diverge from how customers describe the problem and the decision?
5. Which claims are true but not valuable, valuable but unproven, or differentiated but irrelevant to the buyer?
6. What should change, with what evidence and confidence?
7. Which findings are about the words, and which are really about the position?

## Context acquisition

Read `references/CONTEXT.md` and `references/INTERNAL.md`.

### Irreducible minimum

- home product
- the messaging artifact or message set under review

Retrieve before asking. When LMTY is connected it knows the home product, and its report carries the home product's own tracked positioning language alongside each competitor's. If the user names a page, the artifact is the page. If the user asks to "review our messaging" with nothing attached and no CMS connected, ask for the current messaging; do not review from memory and do not write new messaging in its place.

### Strongly preferred context

- the current positioning document or statement: audience, alternative, differentiator, reason to believe
- LMTY positioning and differentiators for each tracked competitor, with change history
- customer calls, interviews, reviews, and research - for vocabulary and decision criteria
- brand voice and approved language
- message performance data: page tests, campaign results, sales feedback on what lands
- win/loss evidence on which claims buyers mentioned

## Source priority for this job

1. the customer's own words for what they value and how they describe it
2. the positioning decision for what the message is meant to carry
3. current competitor positioning and its change record for convergence
4. approved proof for what each claim can be backed by
5. performance data for what has worked, labeled by what it measured
6. the team's read, labeled as such

## Workflow

### Step 1 - Map the hierarchy and audience

Lay out what the message currently says in order: the category it claims, the value it promises, the differentiation it asserts, the proof it offers, the action it asks for. Name the audience it appears to address - and whether that matches the positioning's audience.

If there is no positioning document, reconstruct the implied position from the message and label it as inferred. Do not decide a position for the team.

### Step 2 - Separate the layers

For each line, tag which layer it does: category explanation, value, differentiation, proof, CTA. A message with five differentiation claims and no proof, or category explanation where the buyer already knows the category, is a structural finding before any claim is tested.

### Step 3 - Compare each material claim with competitor language

For each differentiation and value claim, pull what each tracked competitor currently says on the same dimension from LMTY's positioning data, with dates. Mark the claim:

- **still distinct** - no competitor says it, or says the opposite
- **converged** - one or more now say it; note who and since when from the change record
- **parity stated as difference** - the claim was never distinct

Convergence is a fact about the words, not the product. A competitor saying "AI-native" does not make the home product's AI claim false; it makes it generic.

### Step 4 - Check whether differentiation is now parity

Where competitors have converged on the language, ask whether the underlying capability or value still differs. Use current product evidence on both sides. Three outcomes: the words converged and so did the products (real parity); the words converged and the products did not (the message needs sharper proof, not a new claim); or the words diverged and the claim is safe.

### Step 5 - Compare with customer vocabulary and decision criteria

From calls, interviews, reviews, and win/loss: how do customers describe the problem, the outcome they want, and the criteria they decide on? Set the message's words beside theirs. Note:

- terms the message uses that customers never do
- terms customers use that the message never does
- criteria customers decide on that the message does not address
- claims the message leads with that no customer mentioned

Where performance data shows a message working that diverges from interview language, report both. The data measured something; say what, and do not assume the interviews are wrong.

### Step 6 - Sort the claims

Every material claim into one of:

- **differentiated, valued, proven** - keep
- **true but not valuable** - customers do not decide on it; consider demoting
- **valuable but unproven** - customers care, the message asserts, nothing backs it; find or state proof
- **differentiated but irrelevant** - distinct, and no customer evidence it matters; consider demoting
- **generic** - converged; needs sharper proof or a different angle
- **contradicted** - evidence says it is not true; remove

Say the evidence behind each sort.

### Step 7 - Preserve the position

Recommend message changes that serve the existing positioning decision. If the evidence calls the position itself into question - the audience is wrong, the alternative has changed, the differentiator is gone - say that plainly as a finding, and route it. Do not quietly reposition inside a copy review.

### Step 8 - Recommend changes, with evidence and confidence

For each recommended change: what, why, the evidence, and how confident the evidence allows you to be. Suggested wording is welcome where the change is about words; where it is about proof or position, the recommendation is to get the proof or make the decision, not new copy.

### Step 9 - Separate word questions from strategy questions, and hand off

List separately the findings that are really positioning questions, and route them:

| The finding is really | Run |
| --- | --- |
| who this is for, against what, on what basis | `competitive-positioning` |
| how to frame a specific launch | `competitive-launch-readiness` |
| whether the claims across sales assets are supported | `competitive-asset-audit` |
| an internal enablement update | `competitive-enablement-refresh` |
| whether the market convergence is a real shift | `competitive-market-shift-analysis` |
| prospect-facing comparison copy | not yet in this pack; name the page and what it needs |

### Step 10 - Produce the artifact

Use `assets/competitive-messaging-audit-template.md`.

Return it inline, then offer to save it.

## Evidence and reasoning rules

Read `references/TRUST.md` and `references/METHODOLOGY.md`.

Especially for messaging:

- convergence of language is a fact about words; check the products before calling it parity
- customer vocabulary comes from customers - calls, interviews, reviews - not from the team's memory of customers
- performance data measured what it measured; it does not overrule interview language, and interviews do not overrule it
- a claim can be true, distinct, and worthless to the buyer; all three tests apply
- the position is the team's decision; the review tests whether the words carry it
- in bounded-input mode, competitor language and customer vocabulary come only from the supplied material
- the user asking for a rewrite before supplying current messaging gets a request for the messaging, not a rewrite of nothing

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Competitor language and change history from LMTY, customer vocabulary from calls and research, proof from approved sources, performance from analytics.

### LMTY connected, no customer or performance data

Convergence can be tested; customer-language fit cannot. Say so, and mark every vocabulary finding as untested rather than inferring what customers say.

### Customer data connected, no LMTY

Vocabulary fit can be tested; convergence is checked against current public competitor copy, point-in-time and dated, with no history of when it converged.

### Research mode

Competitor language from current public pages, dated; customer vocabulary from public reviews only, labeled as such. Say the review has no internal customer evidence.

### Bounded-input mode

Use only the supplied messaging and any supplied competitor or customer material, and say so at the top. Do not add competitor claims or customer language from memory. Where a test cannot be run from the material, say which and what would run it.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/LMTY.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-objection-response
description: Handle one live competitive objection from a buyer, prospect, rep, or account with current facts, a concise response posture, discovery questions, supportable proof, and honest qualification. Use for "what do I say?", "the buyer just said...", competitor claims about price, features, integrations, security, implementation, or value, and other immediate objection-handling moments - including when the request bundles that objection with broader work such as a comparison document, a deal plan, or a team-wide claim, in which case answer the objection and hand the rest off. Not for a reusable battlecard on its own or for deciding the company's own pricing.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Objection Response

## Mission

Help someone handle one live competitive objection without bluffing, overloading the rep, or turning a buyer concern into a generic feature fight.

The output should be usable in the next minute. Verify the premise, understand what the buyer actually cares about, give a short response posture, provide one or two questions that move the conversation forward, attach proof when it exists, and say when the competitor may genuinely be stronger.

## Use this skill when

- a buyer or prospect just raised a competitor-specific objection
- a rep asks "what do I say?"
- a buyer claims a competitor is cheaper, easier, more integrated, more secure, more complete, or otherwise better on a criterion
- the team needs a concise response to a recurring objection but is asking about one objection rather than a full card
- a PMM wants to turn a verified competitive difference into a response posture and discovery follow-up
- the user needs help separating a buyer perception from the underlying product fact
- the request bundles one live objection with something broader - a comparison document, a deal plan, a "can I tell the team we always..." claim. Take the objection; hand the rest off (Step 12). Do not decline the whole request because part of it belongs elsewhere.

## Do not use this skill when

- the user wants a reusable multi-section competitor card. Use `competitive-battlecard`.
- the user wants a full account or opportunity plan across many objections and stakeholders. Use `competitive-deal-prep`; if the request bundles both, answer the objection and route the rest.
- the job is a formal POC, POV or RFP evaluation plan. Use `competitive-poc-rfp-plan`.
- the user wants to know whether an objection is actually costing deals across many accounts. Use `competitive-win-loss-analysis`.
- the user is deciding whether to change the home product's own price or packaging. Use `competitive-pricing-packaging-review`.
- the underlying task is to redefine company positioning. Use `competitive-positioning`.
- the user wants a full competitor research dossier. Use `competitive-deep-dive`.

## Required outcome

For the objection in front of the user, answer:

1. What exactly did the buyer say?
2. Is the factual premise verified, false, incomplete, or unknown?
3. What decision criterion or concern appears to sit underneath it?
4. What is the shortest supportable response posture?
5. What one or two questions should the rep ask next?
6. What proof can support the response?
7. What should the rep not claim?
8. Where is the competitor legitimately stronger or a better fit?
9. What is current enough to trust, and what remains unknown?

Do not turn this into a full battlecard unless the user asks for one.

## Context acquisition

Read `references/CONTEXT.md`.

### Irreducible minimum

- home product
- objection or buyer claim
- competitor when the objection is competitor-specific

Retrieve before asking.

When LMTY is connected, use it to identify the home product and tracked competitor set before asking the user to repeat either.

When deal or call context is connected, inspect it for the named account or recent objection before asking for details already present there.

If the objection is competitor-specific and the competitor genuinely cannot be retrieved or identified, ask one concise question and stop. Do not pick the most likely competitor.

### Strongly preferred context

- exact buyer wording from a call, note, or user message
- current LMTY state and evidence for the competitor
- CRM stage, segment, and opportunity context
- repeated objection patterns from calls or win/loss
- prior competitive wins and losses
- approved home-product proof
- current security, implementation, pricing, product, or integration documentation relevant to the objection

If internal deal evidence is unavailable, do not invent why the home company wins or which response "usually works".

## Source priority for this job

1. exact buyer or prospect wording for what the objection actually is
2. approved home-product truth for what we can honestly claim
3. current competitor primary evidence and LMTY state for the factual premise
4. repeated win/loss, call, and CRM patterns for field reality
5. validated customer examples or prior wins for proof
6. third-party evidence only when it directly helps establish the disputed fact or buyer perception

Read `references/INTERNAL.md` when internal systems are available.

## Workflow

### Step 1 - Preserve the objection

Write the objection in the buyer's own words when available.

Do not improve it into a stronger argument for either side.

If the user paraphrased a buyer claim, label it as a paraphrase.

### Step 2 - Verify the premise before rebutting it

A buyer can be right, wrong, partly right, or operating from stale information.

Check the material factual claim.

Examples:

- "They have more integrations."
- "They are cheaper."
- "You do not have audit logging."
- "They deploy faster."
- "They are more secure."

Do not convert "not found" into "they do not have it".

Use:

- verified
- partly verified
- not supported by the sources checked
- unknown / insufficient evidence

Carry the relevant date and source into the answer. "Unknown" is not the end of the sentence: name the source that would settle it, so the rep can go and get it before the next call.

### Step 3 - Separate perception from fact

The buyer's belief matters even when the factual premise is wrong.

Do not answer only:

> That is incorrect.

Instead ask what requirement or outcome produced the comparison.

Example:

> If they are saying "more integrations," the useful next question is which integrations are actually required for this workflow and whether breadth or depth of those integrations matters.

The goal is to understand the buying criterion, not win a trivia contest.

### Step 4 - Diagnose the concern underneath it

Classify only as far as the evidence supports.

Common underlying concerns:

- capability fit
- workflow fit
- switching risk
- implementation effort
- security or governance
- price / total value
- breadth or ecosystem
- reliability / vendor trust
- time to value
- future scale

Do not assume every price objection is really a value objection. Use the buyer's words and context.

### Step 5 - Choose the response posture

Prefer one of five postures.

**Acknowledge**

Use when the competitor is genuinely stronger on the criterion.

**Clarify**

Use when the objection is too broad to answer safely.

**Reframe**

Use when the buyer is comparing on a dimension that does not match their actual requirement.

**Prove**

Use when the home product has supportable evidence that directly addresses the concern.

**Qualify**

Use when the requirement may make the competitor the better fit or the deal difficult to win.

These postures can combine, but do not bury the core move under a paragraph of sales language.

### Step 6 - Give the 15-second response

Write natural wording that a person could actually say.

It should:

- acknowledge the concern
- avoid unsupported competitor claims
- redirect toward the buyer's requirement
- use proof only when available

Do not script a long monologue.

### Step 7 - Give one or two discovery questions

The questions should change what happens next.

Good questions:

- identify the exact requirement behind the objection
- reveal how the buyer will evaluate it
- clarify trade-offs
- expose implementation, scale, governance, or workflow needs

Bad questions:

- are rhetorical
- contain an unsupported negative competitor claim
- are designed only to corner the buyer

### Step 8 - Attach proof

Prefer proof that matches the concern.

Examples:

- product documentation
- implementation evidence
- security documentation
- named or approved customer story
- repeated win pattern
- measured outcome

If no proof is available, say so. Do not manufacture a customer example.

### Step 9 - Add deal evidence carefully

When internal call, CRM, or win/loss data is available, distinguish:

- single account example
- repeated pattern
- quantified pattern

A strong quote from one call can illustrate an objection. It does not prove that the objection is widespread.

### Step 10 - Say what not to claim

Add a short warning whenever a rep could easily overreach.

Examples:

- do not say the competitor lacks a capability when it was merely not observed
- do not claim a security certification that is not in approved company proof
- do not say "we always win on implementation" from one anecdote
- do not claim the competitor's motive

If an existing battlecard, talk track or enablement doc was supplied, it is an artifact to verify, not a source. Check its lines against approved proof and current facts, and name the ones the rep must not repeat - a stale price, an integration the approved list says is not available, a certification no approved document states, a "10,000 teams" figure nobody can source. The rep has that card open; a response that does not say which of its lines are wrong leaves them in play.

### Step 11 - Be honest about fit

If the buyer's requirement clearly favors the competitor, say so.

Examples:

- the competitor has a capability the home product does not
- the competitor's packaging is structurally better for this buyer
- the buyer's required integration is unsupported
- the switching cost overwhelms the available advantage

The response can still help the rep clarify the deal without pretending the fit is better than it is.

### Step 12 - Hand off broader work

Answer this one objection fully. Then route the next job instead of silently expanding scope.

When the request asked for both - the objection response *and* a comparison document, a card, a pricing call, a claim for the whole team - produce the objection response only, and say in one line which skill or process owns the rest. Do not produce the other artifact alongside "while you are at it": a comparison document written in the margin of an objection response has had none of the checks that skill would apply, and the rep will send it anyway.

| The user also wants | Run |
| --- | --- |
| a reusable competitor card | `competitive-battlecard` |
| a full account plan | `competitive-deal-prep` |
| a POC, POV or RFP plan | `competitive-poc-rfp-plan` |
| whether this objection is costing deals | `competitive-win-loss-analysis` |
| a company pricing or packaging decision | `competitive-pricing-packaging-review` |
| a full positioning decision | `competitive-positioning` |
| a full competitor profile | `competitive-deep-dive` |
| launch-specific framing or enablement | `competitive-launch-readiness` |

### Step 13 - Produce the artifact

Use `assets/objection-response-template.md`.

Default to concise. This is a moment-of-use artifact.

Return it inline, then offer to save it if the user wants a file.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for objection handling:

- a buyer belief is evidence of buyer perception, not proof of the underlying product fact
- absence is not evidence
- do not invent why the competitor built or priced something a certain way
- do not invent customer stories
- one deal is one deal
- internal claims still need approved proof when they are material
- where the competitor is stronger belongs in the answer
- a source's interpretation is that source's, not yours and not a fact. LMTY's `implication` sentence on a change, a rep's risk reason in the CRM, a battlecard's line, a win/loss interviewer's paraphrase: quote it and say whose it is. "LMTY reads this as a shift to self-serve" is honest; "this signals a shift to self-serve" is a claim you did not verify.

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Use market truth, the actual objection, deal context, prior outcomes, and approved proof.

### LMTY connected without internal deal context

Produce a market-grounded response.

Do not claim the objection is common, do not say what "usually wins," and do not invent prior examples.

### Research mode

Verify the current public facts and produce a point-in-time response.

State that there is no longitudinal or internal deal evidence.

### Bounded-input mode

Use only the supplied material, and say so at the top.

Do not fill missing competitor facts or home-product proof from memory. That includes reputation: "Northwind has a broad ecosystem" is memory, even when it favors the buyer's claim and even when it is probably true. A premise the supplied material cannot check is **unknown**; write that, and name what would check it - the competitor's integration directory, the approved integrations list - so the user can go and get it.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/LMTY.md`
- `references/INTERNAL.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-poc-rfp-plan
description: Plan a head-to-head evaluation - a POC, POV, pilot, bake-off, or RFP response - against a competitor or competitive set, with the buyer's requirements mapped, table stakes separated from the criteria that will decide it, each differentiator tied to a proof event, the questions that expose real trade-offs, where the competitor is stronger, and the conditions under which the team should not proceed. Use for "we're going into a POC against X", "help us shape the RFP response", "what should we prove in the POV", "how do we set up the evaluation around what matters", and scoring or requirement matrices. Not for general deal prep, one live objection, or a reusable battlecard.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive POC / RFP Plan

## Mission

Help a team enter a formal, criteria-driven evaluation against a competitor with a plan built on what the buyer actually needs to see - not on the competitor's checklist, not on the home product's favorite demo, and not on claims nobody can prove in the room.

The plan says which requirements are table stakes, which will decide the evaluation, what proof event demonstrates each differentiator, which questions surface trade-offs the buyer has not yet considered, where the competitor will win, and when the honest advice is not to compete.

## Use this skill when

- a POC, POV, pilot, bake-off, or technical evaluation against a named competitor is starting or being scoped
- an RFP, RFI, or security questionnaire has arrived and the team wants to shape the response competitively
- someone asks what to prove, what to demonstrate, or how to set the evaluation criteria
- a buyer has sent requirements or a scoring matrix and the team needs to read it competitively
- a request bundles the evaluation plan with a live objection or an account overview - take the evaluation, route the rest (Step 10)

## Do not use this skill when

- the job is preparing for the account in general - stakeholders, deal state, next meeting. Use `competitive-deal-prep`.
- the user needs words for one objection now. Use `competitive-objection-response`.
- the user wants reusable guidance against a competitor across accounts. Use `competitive-battlecard`.
- the user wants to understand a competitor's product in depth outside an evaluation. Use `competitive-deep-dive`.
- the user is asking whether the home product's own pricing should change to win the RFP. Use `competitive-pricing-packaging-review`.

## Required outcome

For the one evaluation in front of the user, answer:

1. What is the evaluation trying to decide, for whom, by when?
2. What did the buyer state as requirements, in their words?
3. Which requirements are mandatory, which are table stakes, and which will actually differentiate?
4. For each differentiating criterion, what is verified about the competitor and the home product?
5. Where does proof matter more than a claim, and what proof event demonstrates it?
6. Which questions expose workflow, scale, governance, or implementation trade-offs the buyer should weigh?
7. Where is the competitor stronger, and is that criterion decisive?
8. Which criteria are irrelevant to this buyer and should not be overplayed?
9. Under what conditions should the team qualify out or decline to bid?
10. What is current enough to rely on, and what is unknown?

## Context acquisition

Read `references/CONTEXT.md` and `references/INTERNAL.md`.

### Irreducible minimum

- home product
- the evaluation context: what kind of evaluation, and the requirements or criteria as far as they exist
- the competitor or competitive set, when known

Retrieve before asking. When LMTY is connected it knows the home product and tracked set. When opportunity data or calls are connected, the account name finds the requirements the buyer has already stated.

If no requirements exist yet - the buyer has said "let's do a POC" and nothing more - that is a valid state, and the artifact changes shape: the objective, the questions that would establish criteria with the buyer, and the no-go conditions that already apply. No requirements map, no proof plan, no differentiator table. Filling those from what buyers "usually" want is inventing the buyer's requirements, and the plan will be built on them.

If the competitor is unknown and cannot be retrieved, plan against the tracked set the buyer is most likely evaluating and say so, or ask one question if the plan cannot proceed without it.

### Strongly preferred context

- the formal requirements document, RFP, scoring matrix, or questionnaire
- buyer priorities from calls, in their words
- current competitor capabilities from LMTY and primary evidence, with dates
- approved home-product proof, documentation, security and technical material
- prior POCs, POVs, or RFP responses against this competitor
- deal context: stage, stakeholders, timeline

## Source priority for this job

1. the buyer's stated requirements and priorities, from the document and the calls
2. approved home-product documentation for what can be demonstrated and claimed
3. current competitor evidence and LMTY state for the competitor's side of each criterion
4. prior evaluations against this competitor, labeled by how comparable they were
5. the team's read of what will matter, labeled as assumption

## Workflow

### Step 1 - State the evaluation objective

In one or two lines: what decision the evaluation feeds, who evaluates, who decides, the timeline, and the format (structured scoring, open POC, written RFP response, security review).

If the format is a written RFP, note that the competitor is answering the same questions and the buyer will compare answers side by side.

### Step 2 - Extract the stated requirements

List every requirement the buyer has stated, verbatim or closely paraphrased and labeled, with its source. Keep the buyer's numbering if there is one.

Distinguish:

- **stated in the document**
- **stated on a call** by a named stakeholder
- **implied** by the buyer's vocabulary or by a requirement's phrasing
- **assumed** by the team

Requirements written in a competitor's marketing language are a signal: note which, because they suggest who shaped the list.

### Step 3 - Classify each requirement

For each requirement, one of four classes:

- **Mandatory** - the buyer scores it pass/fail, whatever the products do. Keep the buyer's own label. A mandatory requirement the home product meets is proved fast and without drama; one it does not meet, or meets only by a workaround, goes straight to the no-go conditions (Step 9) - it is not "differentiating", it is the evaluation.
- **Table stakes** - weighted, but both products meet it and the buyer has not signalled it matters. Prove it efficiently; do not spend evaluation time winning it.
- **Differentiating** - weighted; the products meet it differently, or one does not; and the buyer has signalled it matters, or the weight says so.
- **Irrelevant to this buyer** - in the list, but nothing the buyer has said suggests it will weigh, and the weight is low. Do not overplay it, even if the home product wins it. A requirement the sponsor has flagged as inherited or suggested by the incumbent is a candidate for this class - and a question for the next call, not a unilateral demotion.

Say which classification rests on buyer evidence (the document's own type and weight, a stakeholder's words) and which on the team's read.

### Step 4 - Verify both sides of each differentiating criterion

For each differentiating criterion:

- home product: what approved documentation says can be demonstrated, and any limits
- competitor: what current evidence shows, with confidence and date

Use verified / partly verified / not observed in the sources checked / unknown. A competitor capability not observed on their public material is unknown, not absent - and in a POC the buyer will find out.

### Step 5 - Decide where proof beats claims

For each differentiating criterion the home product is strong on, decide whether it will be won by a claim, a document, or a demonstration. Prefer demonstration wherever the buyer could reasonably doubt the claim or the competitor could make the same one.

### Step 6 - Map each differentiator to a proof event

Build the proof plan: for each differentiating criterion, the specific thing the buyer will see or do - a live configuration, a data set run, a workflow walked end to end, a document delivered, a reference call - who runs it, what "pass" looks like, and what it depends on.

A differentiator with no proof event is a claim. Either design one or stop leaning on it.

### Step 7 - Design the questions that expose trade-offs

Write questions for the buyer that surface what a checklist hides: workflow fit, scale behavior, governance, implementation effort, migration cost, what happens at the edges.

These questions must be buyer-centered - they help the buyer evaluate well. They are not traps that only work if the buyer does not understand their own requirement. Do not write questions whose value depends on the buyer being misled about the competitor.

### Step 8 - Name where the competitor is stronger

For each differentiating criterion the competitor wins, say so, say whether the buyer has signalled it as decisive, and say what the honest response is: a workaround with its real cost, a reframe the buyer's own priorities support, or acknowledgment.

Then the criteria the home product wins that this buyer has not said they care about: list them, and say not to overplay them.

### Step 9 - Set the qualification and no-go conditions

State the conditions under which the team should qualify out, decline to bid, or scope down: a mandatory requirement the home product cannot meet, an evaluation designed around the competitor's strengths that the buyer will not adjust, a timeline the proof plan cannot fit, a buyer whose decision has already been made.

Write these before the evaluation starts. They are much harder to write honestly afterwards.

### Step 10 - Hand off broader work

| The user also wants | Run |
| --- | --- |
| the account picture beyond this evaluation | `competitive-deal-prep` |
| words for one objection now | `competitive-objection-response` |
| a reusable card for this competitor | `competitive-battlecard` |
| the competitor understood in depth | `competitive-deep-dive` |
| whether our price or packaging should change to win | `competitive-pricing-packaging-review` |

### Step 11 - Produce the artifact

Use `assets/evaluation-plan-template.md`.

Return it inline, then offer to save it. If the user asked for RFP answer text, draft only answers approved documentation supports. Mark for an owner's confirmation - product, security, or legal - every answer that describes a workaround for a requirement the product does not meet natively, every security or compliance answer, and every answer that commits to a timeline or a migration outcome. An answer that says "via the public API" to a mandatory requirement is a commitment the product team has to be willing to stand behind in week two.

## Evidence and reasoning rules

Read `references/TRUST.md` and `references/METHODOLOGY.md`.

Especially for evaluations:

- the buyer's requirements are the criteria; the competitor's feature list is not
- a claim that cannot be demonstrated in the evaluation is a liability, not an asset
- unknown is a state; in a POC the buyer will resolve it, so plan for that
- a question that only works if the buyer is misled is not a question this skill writes
- the user asking for a claim the evidence cannot support gets a refusal and the supportable version, not a softer wording of the false one
- a prior evaluation against this competitor is one evaluation; say how comparable it was

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Requirements from the document and the calls, competitor side from LMTY and evidence, home side from approved documentation, history from prior evaluations.

### LMTY connected, no internal context

Competitor side is current; requirements and home-product proof come from the user. Label every requirement as user-reported and every home claim as needing confirmation against approved documentation.

### Research mode

Competitor side from current public evidence, point-in-time, dated. Say there is no tracked history and that the competitor's capabilities are as observed, not verified.

### Bounded-input mode

Use only the supplied material - typically the RFP and whatever the user attached - and say so at the top. Do not add competitor capabilities, home-product claims, or proof from memory. Where the material cannot verify a requirement on either side, write unknown and what would resolve it.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/LMTY.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-positioning
description: Develop, pressure-test, or refresh product positioning against the alternatives customers actually consider. Use when defining a market position, revising positioning after competitor or category changes, preparing a positioning brief, clarifying differentiation, or testing whether current messaging still reflects customer value and the competitive landscape.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Positioning

## Mission

Help a PMM establish a credible, useful competitive position grounded in customer progress, real alternatives, current market behavior, and company strengths.

The skill should create the context that makes messaging easier. It should not jump straight to taglines.

## Use this skill when

- defining or refreshing product positioning
- a competitor or category change may have weakened the current position
- the team struggles to explain why customers should choose the product
- a new segment, product, or GTM motion needs a position
- messaging feels generic or increasingly similar to competitors
- leadership asks how the company should be framed relative to alternatives
- a launch or pricing change creates a positioning question

## Do not use this skill when

- the user only wants a competitor profile. Use `competitive-deep-dive`.
- the user wants finished campaign copy without first needing positioning analysis.
- the main question is a pricing decision. Use `competitive-pricing-packaging-review`.
- the question is about a specific upcoming launch or release, including whether a capability is parity, catch-up, or real differentiation. Use `competitive-launch-readiness`.
- the task is a one-off sales response. Use `competitive-battlecard`.
- the position is settled and the question is whether the current copy or message hierarchy still carries it. Use `competitive-messaging-audit`.
- the question is why deals are being won or lost, from deal evidence. Use `competitive-win-loss-analysis`, and bring its findings here.

## Required outcome

Produce a positioning brief that answers:

1. What alternatives do customers use or consider?
2. Which customers care most about the value we can uniquely deliver?
3. What attributes or capabilities are meaningfully different?
4. Why do those differences matter to the customer?
5. What category or frame makes those differences easiest to understand?
6. What has changed in the market that affects the position?
7. What claims are credible, ownable, and defensible enough to repeat?
8. Where is the current position vulnerable or unsupported?

## Context acquisition

Read `references/CONTEXT.md`. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- product or offer
- target customer or segment
- current positioning or website copy if it exists

Strongly preferred:
- LMTY competitor set, report, and relevant changes
- win/loss or customer interviews
- sales calls and objection themes
- current strategy and GTM motion
- pricing and packaging
- product strengths and proof
- category and adjacent alternatives

Do not treat the tracked competitor set as the complete alternative set. Customers may compare against manual work, adjacent products, internal builds, services, or doing nothing.

## Source priority for this job

1. customer and win/loss evidence for what matters and what alternatives are considered
2. product truth for what the home product can actually deliver
3. LMTY for current competitor state and changes over time
4. competitor primary sources for their claims and offer
5. company strategy and target segment
6. reviews, community, analysts, and third-party evidence for perception

## Workflow

### Step 1 - Frame the customer's progress

Define the functional, emotional, and social jobs when evidence supports them.

Identify:
- situation or trigger
- current struggle
- desired progress
- consequences of staying with the current alternative

Avoid demographic positioning without causal relevance.

### Step 2 - Identify competitive alternatives

List what customers would do if this product did not exist.

Separate:
- direct competitors
- adjacent alternatives
- internal or manual approaches
- status quo or no decision

Rank by actual customer/deal relevance, not market fame.

### Step 3 - Map the current market

For the alternatives that matter, establish:
- target customer
- core promise
- key capabilities
- pricing/packaging if material
- proof and trust signals
- recent positioning or product changes

Use LMTY history to distinguish a durable position from a recent messaging experiment when possible.

### Step 4 - Identify unique attributes

Find attributes the home product has that relevant alternatives do not share, or executes in a meaningfully different way.

Use these differentiation lenses where useful:
- feature/capability
- pricing/packaging
- market segment
- technology with a user-visible consequence
- channel/distribution
- customer experience

Do not label an attribute unique until the evidence supports it.

### Step 5 - Translate attributes into value themes

For each candidate attribute ask:
- who cares?
- in what situation?
- what outcome changes?
- what proof exists?
- how easy is this for a competitor to copy?

Discard differences that do not matter to the target customer.

### Step 6 - Choose the market frame

Decide which context helps the customer understand the value fastest.

Test whether the position is primarily:
- market capture in an understood category
- a focused subcategory or segment position
- market creation that requires problem education or reframing

Do not create a new category merely to sound unique.

### Step 7 - Map switching forces

For the target customer, document:
- push away from the current situation
- pull toward the new solution
- anxiety about adopting it
- habit or switching cost holding them back

Use this to reveal which parts of the position need proof, not just stronger copy.

### Step 8 - Draft the positioning core

Produce:
- target customer
- competitive alternatives
- differentiated attributes
- value themes
- market/category frame
- reasons to believe
- positioning statement for internal use
- messaging implications, not full campaign copy unless requested

### Step 9 - Pressure-test against recent change

Use relevant LMTY changes or current research to ask:
- did a competitor move into our claimed territory?
- did a new alternative change the evaluation set?
- did pricing/packaging alter how value is perceived?
- did our own product change enough to make old positioning stale?

### Step 10 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and". Answer the one this skill owns, in full. For the rest, name the skill that owns it and stop there.

This is not a refusal and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Pricing** - the position depends on a packaging change we have not decided. That is a separate decision: run `competitive-pricing-packaging-review` with this analysis as input.

One line per area the work touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| field talk tracks, objection handling, or a rep-facing card | `competitive-battlecard` |
| a full profile of one competitor | `competitive-deep-dive` |
| a decision-oriented version for leadership | `competitive-executive-market-brief` |
| launch framing, claims, or enablement for a release | `competitive-launch-readiness` |
| a recurring digest of what changed | `competitive-market-briefing` |
| whether a pattern is a real shift or noise | `competitive-market-shift-analysis` |
| a pricing or packaging decision | `competitive-pricing-packaging-review` |

The failure this prevents is quietly answering the other half yourself. It looks helpful, and it produces a recommendation built on this skill's evidence alone, without the context the other decision actually needs.

### Step 11 - Produce the artifact

Use `assets/positioning-brief-template.md`.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for positioning:
- competitor marketing copy proves what they claim, not what customers believe
- a customer quote proves one customer's perception unless repeated evidence exists
- "best", "only", and category leadership claims require strong evidence
- a technological difference matters only if it changes a customer-relevant outcome
- do not hide where a competitor is stronger

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without LMTY:
- use current primary-source research for the alternatives that matter
- state that historical movement and persistence of positioning claims may be unknown

Without customer evidence:
- produce a market-grounded positioning hypothesis
- clearly mark customer-value assumptions that need validation

Without product strategy context:
- avoid prescriptive segment or category decisions

## Composition

Each companion below owns a decision this skill should not make on its own evidence. The hand-off step is where the request's own follow-on question gets named.

Common companions:
- `competitive-deep-dive`
- `competitive-market-shift-analysis`
- `competitive-pricing-packaging-review`
- `competitive-launch-readiness`
- `competitive-battlecard`
- `competitive-executive-market-brief`

## Quality bar

Read `references/QUALITY.md`.

A strong result should make it obvious:
- who the product is for
- what it replaces or competes with
- why the difference matters
- what proof makes the story believable
- how recent market movement affects the position

## Examples of activating requests

- "Help me position this product against the alternatives customers actually use."
- "Our competitors all sound like us now. Pressure-test our positioning."
- "Has the market moved enough that we should change our position?"
- "Build a positioning brief using our customer calls and LMTY data."
- "What is our strongest defensible position for enterprise buyers?"

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md`
- `references/TRUST.md`
- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/QUALITY.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-pricing-packaging-review
description: Analyze or pressure-test the home product's own pricing and packaging using current competitor offers, recent pricing changes, customer and deal evidence, and company context. Use when the deliverable is a monetization decision - reviewing a pricing change, planning packaging, deciding whether the company should respond to a competitor price move, or asking what market evidence should inform pricing. Not for a live buyer price objection, a pricing-news briefing, or profiling a competitor whose pricing moved.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Pricing and Packaging Review

## Mission

Help a PMM understand how current market pricing and packaging should inform a pricing decision without pretending competitor prices determine the correct price.

This is an evidence and decision-support skill, not a substitute for willingness-to-pay research, unit economics, or financial modeling.

## Use this skill when

- reviewing or planning a pricing or packaging change
- a competitor changed price, packaging, free tier, limits, or included features, and the question is what we should do about it
- someone asks what changed in competitor pricing over a period and what it means for ours
- leadership asks how the company compares on price and value
- a launch introduces a new paid capability or tier
- a team wants to understand market packaging patterns
- a PMM needs a pricing/packaging section for a strategy or launch review

## Do not use this skill when

- the user asks for a full financial model or revenue forecast
- there is no pricing, packaging, entitlement, or monetization question
- the primary question is broad positioning. Use `competitive-positioning`.
- the buyer is objecting to price in a live deal and the user needs to know what to say next. Use `competitive-objection-response`. A buyer price objection is not a monetization decision.
- the deliverable is a briefing for an audience and pricing is one subject among several. Use `competitive-market-briefing`, or `competitive-executive-market-brief` for leadership. A request that is only about pricing and ends in what we should do belongs here, however it is phrased.
- the request is to profile a competitor, or to explain why a competitor changed price. Use `competitive-deep-dive`. Pricing appearing in a request does not make it a pricing decision.

## Required outcome

Produce an analysis that answers:

1. What is the home offer today?
2. What are the relevant competitors charging and how is value packaged?
3. What changed recently?
4. Which comparison dimensions matter to customers?
5. Where is the home offer advantaged, exposed, or simply different?
6. Which pricing hypotheses are supported by market evidence?
7. What cannot be concluded without internal or primary research?
8. What decision questions should the pricing team resolve next?

## Context acquisition

Read `references/CONTEXT.md`. If call, CRM, win/loss or company-knowledge sources are connected, read `references/INTERNAL.md` before using them.

Minimum useful context:
- home product pricing/packaging or proposed change
- target segment
- competitor set or permission to identify it

Strongly preferred:
- LMTY pricing/packaging report sections and changes
- win/loss and objection data
- usage/adoption by plan
- conversion, expansion, churn, discounting, and deal data
- willingness-to-pay or pricing research
- gross margin or cost-to-serve constraints when relevant
- product roadmap and packaging goals

## Source priority for this job

1. official home-company pricing and packaging truth
2. LMTY current and historical pricing/packaging evidence
3. competitor pricing pages, docs, terms, and public sales material
4. CRM, win/loss, and sales calls for actual buyer reactions and discounting
5. usage and revenue data for internal economics
6. pricing research and customer interviews
7. third-party estimates only when clearly labeled

## Workflow

### Step 1 - Define the decision

Clarify whether the job is primarily:
- competitive scan
- reaction to a competitor move
- new price point
- packaging redesign
- free-to-paid boundary
- feature entitlement
- segment-specific offer
- launch monetization

The method and burden of proof differ.

### Step 2 - Normalize the offers

Build a comparable representation of relevant offers.

Capture where available:
- list price
- billing unit
- billing period
- minimums
- free tier or trial
- plan boundaries
- included/excluded capabilities
- usage limits
- add-ons
- enterprise/custom pricing
- contract expectations

Do not force unlike pricing models into a misleading single price-per-seat table.

### Step 3 - Inspect market movement

Use LMTY changes or historical evidence to identify:
- price increases/decreases
- free-tier removal/addition
- packaging consolidation or fragmentation
- feature movement between tiers
- new usage limits
- new add-ons
- target-segment shifts reflected in packaging

Preserve observed dates.

### Step 4 - Identify customer evaluation dimensions

Use customer and deal evidence when available to understand whether buyers care about:
- headline price
- total cost
- predictability
- procurement simplicity
- included capabilities
- scale limits
- implementation or service
- risk
- ROI or payback

Competitive price differences matter only in the context of perceived value and buying process.

### Step 5 - Diagnose the home offer

Classify meaningful observations:
- **price advantage** - lower comparable price on a dimension buyers care about
- **value advantage** - stronger outcome or bundle at comparable/higher price
- **packaging clarity advantage** - easier to understand or buy
- **exposure** - material disadvantage likely to appear in evaluation
- **intentional premium** - higher price with evidence-backed reason to believe
- **false comparison** - superficially similar pricing that serves different jobs or segments

### Step 6 - Generate hypotheses, not fake certainty

Examples:
- competitor bundling may increase pressure on a paid add-on
- removal of a free tier may create an acquisition opening
- a usage-based model may reduce entry friction but increase predictability anxiety

Label each as interpretation and state what internal evidence would confirm or reject it.

### Step 7 - Assess switching forces

For a contemplated pricing change, map:
- push created by current pricing friction
- pull of the proposed offer
- anxiety about cost, lock-in, or unpredictability
- habit and switching costs

### Step 8 - Produce decision questions

A strong review ends with the questions the team actually needs to resolve, such as:
- Are we monetizing a capability customers already view as table stakes?
- Is a competitor price change appearing in loss reasons or only in internal anxiety?
- Does our packaging map to how customers buy and expand?
- Are we deliberately premium or accidentally expensive?

### Step 9 - Hand off what you do not own

Requests routinely arrive as two questions joined by "and". Answer the one this skill owns, in full. For the rest, name the skill that owns it and stop there.

This is not a refusal and it is not a disclaimer at the bottom. Write it as a line the reader can act on:

> **Positioning** - the real question is what we stand for, not what we charge. That is a separate decision: run `competitive-positioning` with this analysis as input.

One line per area the work touched, named explicitly:

| The request also wants | Say to run |
| --- | --- |
| one live buyer objection or "what do I say?" | `competitive-objection-response` |
| a reusable rep-facing card | `competitive-battlecard` |
| a market position, messaging, or differentiation | `competitive-positioning` |
| a full profile of one competitor | `competitive-deep-dive` |
| a decision-oriented version for leadership | `competitive-executive-market-brief` |
| launch framing, claims, or enablement for a release | `competitive-launch-readiness` |
| a recurring digest of what changed | `competitive-market-briefing` |
| whether a pattern is a real shift or noise | `competitive-market-shift-analysis` |

The failure this prevents is quietly answering the other half yourself. It looks helpful, and it produces a recommendation built on this skill's evidence alone, without the context the other decision actually needs.

### Step 10 - Produce the artifact

Use `assets/pricing-review-template.md`.

## Evidence and reasoning rules

Read `references/TRUST.md`.

Especially for pricing:
- public list price may not equal realized price
- missing public pricing does not imply higher or lower pricing
- competitor price moves do not prove elasticity, growth problems, or strategy
- do not recommend price changes solely to match competitors
- separate market evidence from internal economics and willingness-to-pay evidence

## Graceful fallback

Read `references/DEGRADATION.md`. For what LMTY can and cannot do, read `references/LMTY.md`.

Without LMTY:
- create a point-in-time offer map from primary sources
- do not claim when a price changed without dated evidence

Without internal revenue/deal data:
- stop at market hypotheses and decision questions
- do not make a definitive pricing recommendation

## Composition

Each companion below owns a decision this skill should not make on its own evidence. The hand-off step is where the request's own follow-on question gets named.

Common companions:
- `competitive-positioning`
- `competitive-launch-readiness`
- `competitive-market-shift-analysis`
- `competitive-deep-dive`
- `competitive-executive-market-brief`

## Quality bar

Read `references/QUALITY.md`.

A strong result helps a pricing team distinguish:
- what competitors charge
- how value is packaged
- what buyers appear to care about
- what recently changed
- what that may imply
- what only internal or primary research can answer

## Examples of activating requests

- "Northwind raised prices. What should we examine before changing ours?"
- "Compare our packaging against these six competitors and pressure-test our new plan structure."
- "Are we charging separately for something the market treats as table stakes?"
- "Build a pricing and packaging review for the exec team."
- "What changed in competitor pricing over the last quarter and what questions should it raise for us?"

## References

- `references/METHODOLOGY.md`
- `references/LMTY.md`
- `references/TRUST.md`
- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/QUALITY.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-roadmap-review
description: Turn market and customer evidence into product questions worth investigating - for a product area or a roadmap under review - without treating competitor features as a roadmap. Establishes what competitors actually did and whether it is independent and buyer-relevant, pulls the company's own customer evidence for the same need, checks whether the problem is already solved another way, and frames each gap as table-stakes risk, differentiator opportunity, copycat noise, or evidence gap, with the evidence still needed before anyone prioritizes. Use for "what should product investigate based on the market", "competitors keep adding this - does it matter for our roadmap", "review this roadmap against market and customer evidence", "are we missing something". Not for deciding whether a market pattern is real, framing a launch, or making the priority call.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Roadmap Review

## Mission

Help product see what the market and customers are saying about a product area, sharply enough to investigate the right things - and stop the review from becoming a list of competitor features to copy.

The output is questions worth investigating, each grounded in what competitors did, what the company's own customers said and did, and what the home product already does; each classified honestly as a table-stakes risk, a differentiation opportunity, copycat noise, or an evidence gap; and each with the evidence named that would have to exist before it could be prioritized. The review does not rank the roadmap.

## Use this skill when

- product or PMM asks what the market suggests product should look into
- competitors keep adding something and someone asks whether it matters for the roadmap
- a roadmap or product area is to be reviewed against market and customer evidence
- someone asks "are we missing something important?" about a product area
- a request bundles the review with a shift verdict or a launch plan - review the area, route the rest (Step 9)

## Do not use this skill when

- the first question is whether the market pattern is real at all - one move or a shift. Use `competitive-market-shift-analysis`, and bring its answer here.
- the feature is already being launched and needs competitive framing. Use `competitive-launch-readiness`.
- the question is what the whole company should do in response to a validated market move - pricing, sales, marketing, product together. That is not yet in this pack; give product's part here and say the cross-functional plan is a separate job.
- the question is a company pricing or packaging decision. Use `competitive-pricing-packaging-review`.
- the user wants one competitor understood in depth. Use `competitive-deep-dive`.

## Required outcome

For the product area or roadmap scope in front of the user, answer:

1. What product decision or area is under review, and who owns it?
2. What have competitors actually done here, when, and is the movement independent?
3. Is it buyer-relevant - is there evidence buyers care, beyond the competitors doing it?
4. What do the company's own customers say and do about the same need?
5. Is the problem already solved another way in the home product?
6. What are the questions worth investigating, framed as customer problems or strategic questions?
7. For each: table-stakes risk, differentiator opportunity, copycat noise, or evidence gap?
8. What evidence is missing before anything here could be prioritized?

## Context acquisition

Read `references/CONTEXT.md` and `references/INTERNAL.md`.

### Irreducible minimum

- home product
- the product area or roadmap scope

Retrieve before asking. When LMTY is connected it knows the home product and the competitors' current state and change history for any area. When product planning, analytics, or customer research sources are connected, the area name finds the roadmap items, the usage data, and the customer evidence.

If the scope is the whole roadmap, that is a valid scope; work area by area and say which areas the evidence reached.

If neither a product area nor a roadmap can be established, ask one question. Then stop.

### Strongly preferred context

- LMTY report, evidence, and change record for the area, per competitor
- the roadmap, specs, or PRDs for the area
- customer research, calls, interviews, and support themes touching the need
- product analytics: adoption and usage of the relevant capabilities, including the existing alternative in the home product
- win/loss evidence where the need appears in buyer criteria
- company strategy or priorities, when the user can share them

## Source priority for this job

1. the company's own customer evidence - calls, research, support, win/loss - for whether the need is real for its customers
2. product analytics for what customers do, as distinct from what they say
3. current competitor evidence and change record for what competitors did and when
4. the roadmap and specs for what is already planned or built
5. the team's read, labeled as such

## Workflow

### Step 1 - Name the decision under review

State the product area, the decision the review feeds (invest, investigate, deprioritize, defend), who owns it, and when it is being made. If the user's framing is a competitor feature ("they added X"), restate the area as the customer need X serves, and review that.

### Step 2 - Establish competitor movement

From the change record and current state: which competitors did what in this area, when, from what evidence. Distinguish shipped from announced from marketed. Note the tier or plan it landed in.

### Step 3 - Judge independence and buyer relevance

Independence: did several competitors move separately, or did one move and others follow, or did one move and the rest only talk? A pattern that is one vendor plus echoes is one vendor.

Buyer relevance: is there evidence - customer calls, buyer criteria in win/loss, analyst or review language, LMTY evidence of buyer-facing emphasis - that buyers weigh this? Competitors doing something is evidence that competitors think buyers want it, not that they do.

If the question of whether the pattern is real is the whole question, stop and route to `competitive-market-shift-analysis`.

### Step 4 - Pull the company's own customer evidence

For the same need: what have this company's customers and prospects said - in calls, interviews, support tickets, feature requests, win/loss? Count it and date it. Note where the vocabulary matches the competitor's feature and where customers describe the problem differently.

A single customer asking is one customer. A repeated request across a stated number is a pattern in requests. Neither is yet demand.

### Step 5 - Check what customers do

From analytics where available: is the need already being met another way in the home product - a workaround, an integration, an adjacent capability - and how many use it? Does usage support or contradict the stated demand? A loudly requested capability whose existing workaround nobody uses is a finding; so is a quietly used workaround nobody requested.

Where telemetry contradicts stated demand, report both and do not resolve it by preferring one. Say what would resolve it.

### Step 6 - Check whether the problem is already solved

Against the roadmap and current product: is the need addressed, planned, addressed differently by design, or absent? A competitor feature the home product serves through a different mechanism is not a gap; it may be a messaging or proof gap.

### Step 7 - Frame the questions and classify each

Write each finding as a question product could investigate, phrased as a customer problem or a strategic question - not as "build X". Classify:

- **table-stakes risk** - buyers increasingly expect it; competitors have it; evidence that its absence costs deals or renewals
- **differentiator opportunity** - customers describe a problem competitors have not solved well, or solved in a way that leaves the home product's approach distinct
- **noise / copycat risk** - competitor movement without buyer evidence; investing would be following
- **evidence gap** - the question is real but the evidence to classify it does not exist yet

Say the evidence behind each classification. Many will be evidence gaps; that is an honest result.

### Step 8 - Name the evidence missing before prioritization

For each question: what would have to be known - customer interviews in a segment, a usage study, a win/loss cut, a cost estimate, a strategic call - before product could weigh it against everything else. Do not rank the questions. Ranking needs company priorities, economics, and capacity the review does not have; if the user supplies them, rank only within what they cover and say so.

### Step 9 - Hand off

| The user also wants | Run |
| --- | --- |
| a verdict on whether the market pattern is real | `competitive-market-shift-analysis` |
| competitive framing for a feature being launched | `competitive-launch-readiness` |
| the company's cross-functional response | not yet in this pack; give product's part and say so |
| a pricing or packaging decision this touches | `competitive-pricing-packaging-review` |
| one competitor's product understood in depth | `competitive-deep-dive` |

### Step 10 - Produce the artifact

Use `assets/roadmap-review-template.md`.

Return it inline, then offer to save it.

## Evidence and reasoning rules

Read `references/TRUST.md` and `references/METHODOLOGY.md`.

Especially for roadmap work:

- competitors shipping something is evidence about competitors; buyer relevance needs buyer evidence
- one competitor is one competitor; one move plus marketing echoes is still one move
- requests are what customers say; telemetry is what they do; a conflict between them is a finding, not a tie-break
- a need the home product meets another way is not a gap
- the review frames questions; it does not rank a roadmap, and it does not write "build X"
- the evidence a classification rests on is stated; "table stakes" without deal or renewal evidence is an opinion
- motive - why a competitor built something - is unknown unless sourced

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Competitor movement from LMTY, customer evidence from research and calls, behavior from analytics, plan from the roadmap.

### LMTY connected, no internal sources

Competitor movement and buyer-facing emphasis can be established; the company's own customer evidence cannot. Every question is at best an evidence gap. Say so, and do not infer this company's customer demand from the market.

### Internal sources connected, no LMTY

Customer evidence and behavior can be established; competitor movement comes from current public evidence, point-in-time and dated, with no history. Independence over time cannot be judged.

### Research mode

Competitor movement from public sources, dated. No customer evidence. The review can list what competitors did and the questions that raises; it cannot classify beyond evidence gap.

### Bounded-input mode

Use only the supplied roadmap, research, and market material, and say so at the top. Do not add competitor moves or customer evidence from memory. Classify only where the material supports it.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/LMTY.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: competitive-win-loss-analysis
description: Explain repeated competitive outcomes - why deals are won or lost against a competitor or across a period - from buyer and deal evidence rather than rep folklore, with the cohort defined, buyer-stated reasons separated from rep-entered ones, patterns counted without erasing the cases that contradict them, sample size and bias labeled, and hypotheses to test instead of invented causes. Use for "why are we losing to X", "analyze our wins and losses", "what do buyers actually say when they choose them", "is this objection really costing us deals", and any question about outcomes across more than one deal. Not for one competitor's public profile, one deal's prep, or one objection's response.
license: MIT
metadata:
  author: LMTY
  com.lmty.category: ci
---

# Competitive Win/Loss Analysis

## Mission

Tell the truth about why deals are won and lost against competitors, from what buyers said and what the record shows, at the resolution the evidence supports and no finer.

The output separates what buyers said from what reps wrote, counts what repeats without hiding what does not, says how big and how biased the sample is, connects outcomes to market changes only when the timing holds, and ends with hypotheses worth testing rather than a cause the evidence did not establish.

## Use this skill when

- someone asks why the company is losing, or winning, against a named competitor
- a team wants wins and losses over a period analyzed
- a PMM wants to know what buyers actually say when they choose or reject the home product
- someone asks whether a recurring objection is actually costing deals
- a recurring claim in the field - "we always lose on price to X" - needs checking against the record
- a request bundles the analysis with a positioning decision or an objection script - do the analysis, route the rest (Step 10)

## Do not use this skill when

- the user wants to understand a competitor from public and market evidence rather than from deal outcomes. Use `competitive-deep-dive`.
- the job is preparing one account for its next meeting. Use `competitive-deal-prep`.
- the user needs words for one objection now. Use `competitive-objection-response`.
- validated findings are in hand and the question is what position to take. Use `competitive-positioning`.
- the question is whether a market pattern is real, independent of this company's deals. Use `competitive-market-shift-analysis`.

## Required outcome

For the cohort the user cares about, answer:

1. Which deals, over which window, and how good is the evidence for each?
2. What reasons for winning repeat, in buyers' words?
3. What reasons for losing repeat, in buyers' words?
4. What is specific to each competitor?
5. Which decision criteria show up, and in what order for buyers?
6. Where do buyer-stated reasons and rep-entered reasons disagree?
7. What changed over the window, and does any market change line up with it?
8. What is the sample size, and how is it biased?
9. Which hypotheses are worth testing, and what would test them?
10. What does this imply for other PMM work, and who owns each implication?

## Context acquisition

Read `references/CONTEXT.md` and `references/INTERNAL.md`.

### Irreducible minimum

- home product
- a deal evidence set, or permission and a connected source to retrieve one

Retrieve before asking. When win/loss research, call intelligence, or opportunity data is connected, define the cohort from the user's question - competitor, window, segment - and pull it. Do not ask the user to list the deals.

A single deal can be analyzed as a single deal. It must not be presented as a pattern, and the output must say it is one observation.

If no deal evidence is connected and the user supplied none, say the analysis cannot be done from market data alone, name what would be needed - interviews, call transcripts, closed-won and closed-lost records with competitor fields - and offer to proceed on whatever they can paste.

### Strongly preferred context

- win/loss interviews: buyer quotes and interviewer paraphrase, separately
- call transcripts from the deals, especially the decision call
- opportunity records: outcome, competitor field, stage history, segment, value, dates, rep-entered reasons
- rep notes
- LMTY report and changes covering the window, for what the market did while the deals ran
- home-product pricing, packaging, and product changes during the window

## Source priority for this job

1. the buyer's own words - interview quotes, decision-call transcripts - for why they decided
2. interviewer paraphrase and call summaries, labeled as such
3. opportunity records for outcome, competitor, segment, and dates
4. rep-entered loss and win reasons, as evidence of what the team believed
5. market state and changes during the window, for context, never for cause on their own

## Workflow

### Step 1 - Define the cohort and window

State: which outcomes (won, lost, no decision), which competitor or competitors, which segment or motion, which dates, and why those bounds. Say how many deals the cohort holds and how many have buyer evidence versus record-only.

If the user's framing is "why are we losing to X", the cohort is deals against X - both outcomes. Losses without the wins cannot say what differs.

### Step 2 - Normalize identity and outcome

Reconcile competitor names across sources (the CRM's "Northwind Corp", the call's "Northwind Track", the interview's "their current tool"). Reconcile outcomes: a "closed lost" whose buyer chose nothing is a no-decision, not a competitive loss. Note deals whose competitor is unrecorded or ambiguous and keep them in a separate bucket.

### Step 3 - Separate buyer-stated from rep-entered reasons

For each deal, list reasons in two columns: what the buyer said (source, date) and what the rep recorded (field, date). Do not merge them.

Where only one column exists, say so. A deal with a rep reason and no buyer evidence is a deal whose reason is unknown.

### Step 4 - Extract decision criteria and objection themes

From the buyer column, code the criteria and objections that appear, in the buyer's vocabulary. Keep the buyer's ordering when they gave one ("first speed, then integrations, then price").

Code the rep column the same way, separately.

Keep the buyer's specific mechanism when coding. Three losses a rep would all call "familiarity" may be three different things - the security paperwork already on file, the team already trained, the compliance function already trusting the incumbent - with three different responses. Flattening them into one theme makes the count look stronger and the finding weaker.

### Step 5 - Count what repeats, and keep what contradicts

Count each criterion and theme across deals: appears in N of M deals with buyer evidence. Show the counts. Then show the cases that run against each pattern - the deal lost on price where the buyer said price did not matter, the win where the "usual" advantage was absent.

A pattern is a count with its exceptions attached. A pattern with its exceptions removed is a story.

### Step 6 - Segment when the sample supports it

Split by segment, size, motion, use case, or stage only when each bucket has enough deals with buyer evidence to say anything. Say the threshold you used. Two deals in a bucket is two deals, not a segment finding.

### Step 7 - Connect to market changes only when timing holds

Lay the window against LMTY's change record and the home product's own changes. A market change may explain outcomes only if it happened before the affected deals decided, and the buyer evidence mentions it or its effect. A competitor price cut in September does not explain a loss in June. Say when the timing does not hold.

### Step 8 - Locate the evidence across the usual causes

For each of product, positioning, sales execution, price, implementation, trust, and incumbency: where does the buyer evidence put weight, where does the rep evidence put weight, and where do they disagree? The disagreement column is usually the finding.

### Step 9 - Label the sample

State: total deals, deals with buyer evidence, deals record-only, the window, and every bias you can see - enterprise-heavy, one region, only deals a particular rep flagged, only losses interviewed, interviews conducted by the vendor rather than a third party. Say what the sample cannot speak to.

### Step 10 - Hypotheses, implications, and handoffs

Frame what the evidence suggests as hypotheses with the test that would settle each: more interviews in a segment, a specific question added to discovery, a check of a product claim. Do not write causes the evidence did not establish.

When the user has bundled a second job onto the analysis - a script for the repeated objection, a positioning call - deliver the analysis and route the second job by name. Do not append a draft of it; a script written at the bottom of a win/loss report has had none of the checks the objection skill applies.

Then implications, each routed:

| Implication | Run |
| --- | --- |
| a repeated objection needs a field response | `competitive-objection-response` |
| validated findings should change the position | `competitive-positioning` |
| a competitor needs understanding beyond these deals | `competitive-deep-dive` |
| pricing or packaging appears in the buyer evidence | `competitive-pricing-packaging-review` |
| enablement is teaching what the buyer evidence contradicts | `competitive-enablement-refresh` |
| a market pattern may be real beyond our deals | `competitive-market-shift-analysis` |

### Step 11 - Produce the artifact

Use `assets/win-loss-template.md`.

Return it inline, then offer to save it. Account names and contract values appear only where the reader needs them; quotes are attributed by role, not name, unless the user's audience already has access.

## Evidence and reasoning rules

Read `references/TRUST.md` and `references/METHODOLOGY.md`.

Especially for win/loss:

- the buyer's words are the evidence for why the buyer decided; the rep's field is evidence of what the rep believed
- three deals are three observations
- correlation across a window is not cause; a market change explains a deal only if it preceded it and the buyer connects them
- a pattern's exceptions are part of the pattern
- interviews the vendor conducted are biased toward what the buyer was willing to say to the vendor; say so
- a loss reason of "price" recorded by a rep is the most common folklore in the field, and the buyer evidence usually says something else; check every one
- an interviewer's paraphrase is the interviewer's

## Graceful fallback

Read `references/DEGRADATION.md` and `references/LMTY.md`.

### Fully connected

Cohort from records, reasons from interviews and calls, market context from LMTY.

### Internal sources connected, no LMTY

The analysis proceeds; market context comes from what the buyers said and public evidence. Say there is no tracked record of what the market did during the window.

### LMTY connected, no internal sources

There is no deal evidence to analyze. Say so plainly. Offer what LMTY can say - what changed in the market over the window - as context for an analysis the user could run once evidence is available, not as a substitute for it.

### Bounded-input mode

Use only the supplied deals and documents, and say so at the top. The cohort is exactly what was supplied; label it as such and name its biases. Do not add market changes, competitor facts, or "typical" reasons from memory.

## References

- `references/CONTEXT.md`
- `references/DEGRADATION.md`
- `references/INTERNAL.md`
- `references/LMTY.md`
- `references/METHODOLOGY.md`
- `references/QUALITY.md`
- `references/TRUST.md`

Referenced files: 8 — file references are metadata, not package contents.