Messaging Hierarchy (Jul 12) — Review & Proposed Refinements

Review of the marketing-authored Messaging Hierarchy sheet against positioning/gtm-messaging-matrix.md, the ICP avoid-lists (icp-a §4, icp-b §4/§6b), the persona briefs in deliverables/personas/, and core/. Focus: the Product / Engineering persona, where the sheet drifts furthest from how these buyers actually think.

Overall verdict: the skeleton is right (TOOL vs BUILD split, three buckets, buying-committee roles all match our matrix). The growth and CX columns are mostly usable with small fixes. The product/eng column is written with a growth-tool vocabulary and needs a rewrite before anyone uses it in front of a CTO or AI engineer.

1. Fix-before-anyone-uses-this (blockers)

2. The Product / Engineering column — what marketing missed

This is the section that prompted the review. The sheet treats "Product/Engineering" as one bucket with one voice, and that voice is a growth-tool voice. Three structural problems:

2a. The language-to-USE list is growth vocabulary aimed at engineers

Sheet (Product/Eng): activation rate · time-to-value · feature discovery · agentic interface · click tax · session outcomes.

Four of those six are the Growth PM's words. The matrix's one rule: don't lead with activation curves for an exec or an engineer — lead with the transformation and the architecture. And "click tax" is explicitly Growth-PM vocabulary.

Proposed replacement — Language to USE (CTO / AI Engineer / Developer):

• interface layer · Layer 1 vs Layer 2 ("build the brain, buy the operator") · A2A · MCP · SDK · real-time context · model routing · inference gateway · token cost · golden sets · shadow mode · canary · full-loop evals (Trust Lab, early access)

Proposed replacement — Language to USE (CPO / PM, still product-side but not eng):

• AI-Native · who owns the interface · intent (true intent, unresolved prompts) · ship intents, not screens · time-to-value → time-to-outcome · hours not quarters · data flywheel

Language to AVOID (add to the sheet's list): agentic transformation · production-ready · reliable · revolutionary · end-to-end agent platform · AI-powered · vague "days not months" — plus the sheet's own good entries (chatbot, AI assistant, tooltips). Keep "operator" on the avoid list as a product/feature name (OpenAI collision) — but the phrase "build the brain, buy the operator" is our canonical CTO line; the sheet's blanket "operator" avoid needs that nuance.

2b. The CTO row describes a 2019 CTO, not a 2026 one

Sheet pains: "backlog dominated by UI rework," "every onboarding fix requires a front-end redesign cycle," "legacy interface layer can't keep pace."

Our research (icp-b, real deals, the CTO brief) says the 2026 CTO's actual situation: they're six quarters into an AI initiative, own the build-vs-buy call and the AI cost line, and are under pressure from Anthropic Managed Agents shipping the harness they spent a quarter building. UI-rework pain is real but secondary — it's the CPO's telling of the CTO's problem.

Proposed replacement — CTO pains:

• Internal agent build is stalling — demo still looks like the demo; ~80% of internal AI projects never reach production
• AI cost line is variable and growing; CFO is asking questions (token spend, model choice)
• Anthropic/OpenAI shipped the harness — the interface layer is converging and owning it is no longer a differentiator
• Three teams, three bespoke agent wrappers — no shared evals, no shared governance

Proposed replacement — CTO fears:

• Betting a year of eng time on a layer the model labs commoditize next release ("thin wrapper" burn)
• Vendor lock-in at the model layer (wants model routing / multi-model freedom)
• A security or compliance gap from an agent acting in-product (keep — sheet had this right)
• Being the exec who bought the wrapper instead of building the moat (loops + data = the IP that stays)

How they buy (sheet is right, add): expects to concede-and-position vs. Claude Managed Agents — that's Layer 1; we're Layer 2 above it — and will test the "I could build this in a sprint" objection directly. Proof that lands: Optibus-pattern reference (internal name only; anonymize externally), 20–35% lower token cost, SOC 2 Type II / ISO 27001 / GDPR.

2c. The AI Engineer row misses what actually wins him

Sheet is directionally fine (build-vs-maintain pain, sandbox evaluation) but generic. This persona "has read every Hamel post and will sniff out a thin wrapper in 90 seconds." Generic eval claims are the killshot objection, not a selling point.

Add to pains: hand-building golden sets from production conversations · eval metrics that don't survive contact with real traffic · re-plumbing every time a better model ships.

Add to how-to-win: speak ops vocabulary (shadow mode, canary, golden set, trace) · concede what he knows ("generic eval metrics are useless — agreed; golden sets come from your production conversations") · Trust Lab always framed early access · never pitch "reliable."

"Feels bolted on" (sheet, AI Engineer fears): fine as an internal fear description, but note the "chatbot bolted on top" strawman is banned in external assets — don't let it leak into copy.

2d. Structural: the bucket hides four different buyers

The sheet's single Product/Eng column blends CPO, CTO, PM, AI Engineer, Developer/CIO. Our system already splits these into five briefs with different leads (matrix: CPO → AI-Native transformation; CTO/AI Eng → interface layer; PM → Modernize & True Intent; Developer → build-in-codebase). The Sub-Persona Deep Dive tab is the right instinct — recommend making it the canonical persona layer and demoting the merged bucket to a rollup view. Also: CIO is not a persona we target this cycle (mid-market + enterprise, Exec + Champion depth); the sheet's Developer/CIO merge should be Developer (IC), with CIO noted only as a procurement gate.

2e. "Zero Coding" as the Product key message

This collides head-on with the Build-it-in-your-codebase angle and the Developer plugin story, and it's the vocabulary of the no-code tools we're differentiating from (Chameleon: "no-code speed"). What the PM actually values is iteration without engineering dependency. Say that: "iterate without waiting on the eng queue" — and keep "zero coding" out of anything an engineer might read.

3. Smaller fixes

• Brand Mission ("The agentic interface that transforms user intent into outcomes") — good; aligns with the canonical one-liner. Keep.
• "Engineered Champions" / "engineering champions" (Growth key message + value description) — evocative but undefined; if kept, define it once: the agent drives adoption, so every user activates like they had a champion.
• "Agentic Interface (FE not IP)" — right idea, cryptic shorthand. The canonical phrasing: own Layer 2 (the interface); keep your Layer 1 IP (loops, data, domain).
• Value-proof line for Product/Eng ("Users reach meaningful outcomes in their first conversation…") — fine for CPO; for CTO/AI Eng swap in the matrix's lead proof: 4 products live (Optibus pattern) · 20–35% lower token cost.
• Proof point "Time to Launch AI Native" (Product columns) — right metric family; the canonical phrasing is "ship AI-Native experiences in hours, not quarters." Note icp-b flags the "days not months" family as saturating — always attach a real number.
• Modules rule: anywhere the sheet implies testing/evals or conversation analytics exist today ("Testing, Inspecting, Iterating"), mark Conversational Analytics and Trust Lab as early access — never "available now."
• Value Description "XYZ" placeholders — still unfinished (carried over from the Jul 9 version).
• Key-message column mapping — four columns against three personas (Growth / Product / Product-build? / Engineering) is still unconfirmed; same open item as the last ingest.
• ICP Notes tab is genuinely valuable — the budget realities ($25K CPO / $16K Growth PM discretion, "all the authority, zero budget"), the token-cost math ($400/mo → $4K/mo ballooning; 20–50% savings pays for itself), and "if Growth PM comes in, bring VP Product and VP Eng" all corroborate the matrix's budget-owner note. Worth folding into the persona briefs. The CTO/Engineering row is empty — the in-person notes never covered the persona this review says needs the most work. Telling.

4. What the sheet gets right (keep)

• TOOL vs BUILD as the motion split — matches our land-&-expand vs top-down overlay, and the internal-messaging-pages already build on it.
• Buying-committee roles — Product/Eng = economic buyer, Growth = champion, CX = influencer — exactly matches the matrix's budget-owner note from real deals.
• CX avoid list (AI chatbot · replace your team · automate support · no human needed) — better than most of our own early drafts; keep verbatim.
• Growth avoid list including "agentic layer / interface platform" — correct instinct; architecture language is for engineers, not the Growth PM.
• CPO fear "Board pressure — building Agentic UX & getting it wrong" — sharp, and matches icp-b's discourse research.
• Channels rows are consistent with the persona briefs (Lenny's, PLG newsletters, CX communities, peer referral weight for eng).

5. Open questions for Mickey

1. Confirm the four key-message columns ↔ persona mapping (carried over, still open).
2. May we replace 374% with the verified +344% (AskCody) everywhere, or retire the stat from brand-level messaging?
3. Sub-Persona Deep Dive as the canonical persona layer (merging with deliverables/personas/), with Persona Buckets as rollup — OK?
4. Drop CIO from the persona set (procurement gate only)?
5. Who owns reconciling this sheet with the internal-messaging-pages already in the hub? Two parallel messaging systems is one too many.