Magnet Qualification, Titles & the Deliverable Stack
Qualification — three rules, all must pass
- $100 test — would the ICP plausibly pay $100 for this? If not, the post can't honestly frame it as valuable.
- Sub-hour consumption — usable within an hour of receiving it. A 40-page PDF fails; a scorecard, template pack, or checklist passes.
- ICP-specific — built for one audience's situation. "For everyone" magnets convert no one.
If the magnet fails a rule, flag it before writing and propose the fix (usually: splinter one specific, immediately-usable piece out of the bigger asset and give that away).
Title formulas
A strong magnet name carries a number or dollar figure, a named mechanism, and a stated outcome. Five patterns:
- Named-system blueprint — "The {Result} {Channel} Blueprint"
- AI-tool-branded system — "The {Tool} {Function} System"
- Time-boxed plan — "The {N}-Day {Deliverable} Plan"
- Teardown — "The ${Amount} {Entity} Breakdown"
- Quantified pack — "{N} {Type} Templates That {Result}"
Vague names ("Our Guide to X", "Free Resource") consistently underperform. Rename before writing the post if needed — the name appears in the post and in every DM that fulfils it.
The deliverable stack (part 4 of the post)
The section readers skim to decide "is this worth a comment?" A paragraph fails that test; a list passes.
Rules:
- 4–6 bullets, one line each, "✅" prefix
- At least 2 bullets contain a specific number
- At least 2 bullets carry a parenthetical benefit — why that item matters ("(the exact structure running my agency today)")
- No vague items. "Tips for better outreach" → "7 outreach templates with filled examples". Concrete nouns, countable things.
- Self-test per bullet: "would the ICP comment on a public post to get this specific thing?" Replace any bullet that fails.
Every bullet is a promise. After delivering the post, remind the user the magnet must contain exactly these items before the post goes live — the fastest way to kill this mechanic is delivering less than the stack advertised.
This audit re-runs after every user edit, not just at first delivery. Edited stacks are where broken promises enter: an extra platform, a bonus item, a capability the fulfilment file doesn't actually cover. Check each bullet against the real sendable asset, not against plausibility.