--- name: message-testing-log description: "The learning log discipline pointed at your standing message pillars: which ones actually resonate with a broader buyer audience, tested and recorded honestly, rather than assumed proven everywhere just because they worked in one deal. Use when: A message architecture exists and you want to test whether its pillars actually resonate with buyers broadly, not just in the one deal that first proved each one. A pilot or a set of discovery calls has already run to test a specific message, and you want to record the real verdict — keep, revise, or kill — not just that it 'went well.' Not for: You don't have a message architecture yet — build that first; this log tests pillars that already exist, it doesn't define them. You're checking whether a specific claim has real evidence behind it, not whether the message itself resonates — that's a proof point inventory, a different real question." --- # Message testing log The learning log discipline pointed at your standing message pillars: which ones actually resonate with a broader buyer audience, tested and recorded honestly, rather than assumed proven everywhere just because they worked in one deal. Family: Experimentation · Format: .xlsx · Domain: commercial ## What it is A message testing log is a real, checkable answer to 'does this pillar actually resonate broadly, or did it just work once' — the learning log's exact discipline, pointed at a message architecture's standing pillars instead of a shop-floor hypothesis. A pillar proven in a single deal isn't the same as a pillar tested across a real, broader sample of buyers — this log tracks every message test run against each pillar (a discovery-call reaction, a structured pilot, a positioning survey) and honestly records whether the result recommends keeping the pillar as-is, revising it, or killing it. ## When to use it Use it when: - A message architecture exists and you want to test whether its pillars actually resonate with buyers broadly, not just in the one deal that first proved each one. - A pilot or a set of discovery calls has already run to test a specific message, and you want to record the real verdict — keep, revise, or kill — not just that it 'went well.' - You want to know honestly which pillars have never actually been message-tested, rather than assuming every pillar in the standing message is equally validated. Not when: - You don't have a message architecture yet — build that first; this log tests pillars that already exist, it doesn't define them. - You're checking whether a specific claim has real evidence behind it, not whether the message itself resonates — that's a proof point inventory, a different real question. ## How to fill it in - **scopeNotes** — What set of message pillars does this log cover? - **hypotheses** — List every pillar from your message architecture you want tested, even ones you haven't tried yet. - **tests** — For each test: which pillar it relates to, the test type, what actually happened, and your real recommendation — keep, revise, or kill — your own facts, never guessed. - **narrative** — Drafted from the log's own computed coverage. ## What good looks like The example below continues the Beacon Analytics storyline directly from its own message architecture — the cost-of-inaction pillar's reference figure holds up in discovery calls, and the spreadsheet-trust pilot the architecture's own next steps called for surfaces a real, specific objection worth revising the pitch for, while the third pillar stays honestly untested. Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/message-testing-log ## Common mistakes - **Treating a pillar as validated everywhere because it worked in the one deal that first proved it.** — A pillar proven once is a hypothesis worth testing broadly, not a settled fact — this log exists specifically to catch pillars that quietly never get tested past their first win. - **Rounding a mixed result up to a clean 'keep' because part of it went well.** — A specific, named objection from even a minority of a test sample is real signal worth a revision — for example, buyers asking for proof of how a number is calculated, not just being told to trust it. - **Skipping a pillar in the log because it already feels obviously true.** — An untested pillar can't be flagged as a gap — this log only protects the standing message from an unproven claim if every real pillar is actually tested, not just the ones that feel uncertain. ## What it connects to Upstream: - **Message architecture** (`message-architecture`) — The architecture's own pillars are exactly the hypotheses this log tests — including acting directly on the specific next step the architecture itself already named. Downstream: - **Proof point inventory** (`proof-point-inventory`) — A pillar this log confirms resonates broadly is exactly what the proof point inventory should be actively collecting more evidence for — a tested message and a growing body of proof are two different, complementary jobs. ## Where AI helps Judgement — stays with you: - Deciding whether a result actually supports keep, revise, or kill - Deciding which untested pillar to prioritize next Analysis — AI helps: - Tightening a test description from rough notes into a specific, checkable statement - Drafting the narrative from the log's own computed coverage Drudgery — automated: - Identifying which pillars have no tests logged - Identifying which logged tests recommend revise or kill - Exporting to xlsx in the house format --- Message testing log is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Attribution: Katafacts (katafacts.com). ## Using this skill Apply this method as part of whatever broader task, instructions, or deliverable you're already working on -- it's a method to use, not a standalone conversation to start. There is no generation tool for this catalogue yet, so draft the artifact's actual content yourself, following the fields above, the same way a person filling this out by hand would. The canonical guide page and a downloadable worked example (.xlsx) are at https://www.katafacts.com/katas/message-testing-log.