Run in order. Prompts 1-4 build the content engine before you touch acquisition — most founders do the reverse, scale a channel that’s working, then realise three weeks in that they have no inventory of content to feed it. Build the engine, then connect it to the channel, then attach the metrics. Don’t move to prompt 5 until prompts 1-4 have produced a content pillar set, a 90-day cadence calendar with real dates, an AI-drafting prompt you can re-use, and a single piece shipped end-to-end through the system.

1. The content pillar set — three pillars, not seven. “My segment from M2 is [paste]. My offer from M5/M6/M7 is [paste]. The first-five debrief from M8 told me the single biggest converter line was [paste] and the killer objection was [paste]. From that, define the three content pillars I will publish against for the next 90 days — no more than three, ideally three. Each pillar: a one-sentence definition, the segment problem it addresses, the proof I can bring to it (specific numbers, named partners, lived experience — not opinion), the three sub-topics that sit underneath it, and the kill criteria (the type of post that looks on-pillar but isn’t — what I commit to not publishing). Three pillars covers the segment without diluting; seven pillars is a founder who hasn’t decided what they’re for. Output as a 3-row table. If any pillar reads like every other founder in the segment could publish under it unchanged, rewrite — the pillar isn’t yours.”
2. The 90-day cadence calendar — real dates, real slots, no inspiration required. “Build a 90-day cadence calendar starting [next Monday’s date]. For each week: the named slot each piece of content lives in (e.g. Monday 9am — long-form post to LinkedIn under pillar 1; Wednesday — short-form video to Instagram under pillar 2; Friday — newsletter under pillar 3 to the M7 list). Cadence rule: every slot has a pillar, a format, a channel, a day, and a time — none of this ‘when I get to it’. For each of the 12 weeks output the slot grid. Volume guideline for a founder still doing 80% of the work themselves: 3-5 owned-channel pieces per week, not 15. The founder who tries to ship 15 pieces a week from week one ships zero by week four. Output as a 12-week table — week number, date, slots, pillar per slot, format per slot, channel per slot. Leave the title field blank — it gets filled by prompt 3.”
3. The AI-drafting prompt that writes in my voice — not generic AI voice. “My voice rulebook from M6 is [paste — or if not yet built, paste the three short writing samples that sound most like me]. Build the master drafting prompt I will use, unchanged, for every piece of content the AI drafts for me across the 90-day calendar. Structure of the prompt: the voice rules (sentence length, banned words, allowed jargon, French/Australian markers), the credibility stack the AI can reference (named businesses, named partners, named numbers — never invented), the structural template per format (long-form post, short-form caption, newsletter, video script), and the hard rules (no ‘unlock’, no ‘transform’, no ‘6-figure’, no fake scarcity). The output of this prompt is a first draft I edit, not a final piece I publish. The founder edits, the AI drafts — not the reverse. Output the master prompt as one re-usable block, plus the three slot-specific variants (long-form, short-form, newsletter). Test it against one calendar slot before locking it.”
4. The single piece shipped end-to-end — proof the engine runs. “Pick the first slot in week 1 of the calendar from prompt 2. Run the full process now: AI draft from prompt 3, founder edit, fact-check against the credibility stack, schedule to channel, log to the metric scorecard built in prompt 8. Walk through every step in writing. Time-box each step (target: founder edit under 20 minutes, schedule under 5 minutes). At the end, document the friction points — where did the process slow down, where did the AI draft need the most rewriting, where did a step have to be skipped because a piece of the system isn’t built yet. The engine is real the moment one piece has been through it end-to-end. Output the process log, the friction points, and the fix list. Three pieces through the engine in week 1 — not perfect, just shipped — proves the system works. Then connect it to acquisition in prompts 5-7.”
5. The acquisition channel that earned the right to be systemised. “The first-five debrief from M8 named the channel that produced the highest-quality buyer — not necessarily the highest volume, the highest quality. Paste that answer. From that one channel, design the repeatable acquisition mechanic — the actions taken every day, every week, every month, that turn the channel from ‘worked for buyers 1-5’ into ‘produces 3-5 qualified conversations per week, every week, for the next quarter’. Output: the daily action (e.g. 10 personalised outreaches before 10am — not 100 templated), the weekly action (e.g. Friday review of which 10 converted to a reply), the monthly action (e.g. recalibrate target volume based on month’s conversion rate). For each action: who does it (still founder for now, named handoff candidate later), how long it takes, what the named output is. One channel systemised properly beats three channels half-systemised. Output as a daily/weekly/monthly grid.”
6. The conversion-tracking layer — so the system knows when it’s broken. “Build the conversion-tracking layer that sits over the acquisition system from prompt 5. The minimum viable funnel for a single channel: contact → reply → call booked → call held → offer made → close. For each stage: the metric I track, the target rate, the alert threshold (the rate below which the system is broken, not just under-performing). Voice: this is an operating dashboard, not a vanity dashboard. Examples to start from: contact → reply target 15%, alert below 8%; reply → call booked target 50%, alert below 30%; call held → close target 30% for warm / 15% for cold, alert below 15%/8%. Output as a 6-stage table per channel — stage, metric, target, alert threshold, the diagnostic question I ask if the alert fires. The dashboard’s job is not to make me feel good — it’s to tell me which stage to rebuild, fast.”
7. The kill / scale / hold rule per channel — written before it’s needed. “For each acquisition channel currently active, write the kill / scale / hold rule before the data forces the decision in the heat of a bad week. Structure: scale rule — the leading indicators that justify doubling time and money in this channel next month (e.g. close rate above target for 3 consecutive weeks AND CAC below threshold AND volume not capped by my hours). Hold rule — the indicators that say keep running unchanged for another 30 days (within target ranges, no system breakage). Kill rule — the indicators that say stop this channel within the next 7 days and reallocate the time (3 weeks below alert threshold on the killer stage AND no diagnosable fix AND opportunity cost of founder’s time on a tested alternative). Output as a 3-row table per channel. Written before the week of crisis — the rules I’ll follow when the temptation is to defend the channel I emotionally invested in.”
8. The weekly metric scorecard — fewer numbers, more often. “Build the single weekly metric scorecard I look at every Monday morning before any other work in the business. Maximum 10 numbers — fewer if I can. The four categories: content engine (e.g. pieces shipped this week vs calendar target, top-performing piece by channel), acquisition system (e.g. qualified conversations held, conversion at the killer stage, cash collected this week from new customers), retention / system health (e.g. weekly active customers, any alert thresholds tripped this week), founder bottleneck (e.g. hours spent in the business this week vs target, named tasks still only I can do). For each metric: definition, source, target, trigger if missed. Output as a single one-page scorecard template I can fill in inside 15 minutes every Monday. Ten numbers reviewed weekly beats 50 numbers reviewed quarterly. The scorecard is the system’s nervous system — without it, drift goes unnoticed for a quarter.”
9. The SOP document — the system, written down once, runnable by someone else. “Now write the SOP (standard operating procedure) document that captures the full M9 system in one place. Structure: section 1 — the content engine (pillars, calendar, drafting prompt, edit-to-publish workflow, named owner of each slot), section 2 — the acquisition system (channels, daily/weekly/monthly actions, conversion-tracking, kill/scale/hold rules), section 3 — the weekly scorecard (the 10 numbers, where to find them, what to do if any alert fires), section 4 — the cadence calendar for the next 90 days. Voice: written so that someone competent but new to the business can read it on a Monday morning and run the week end-to-end without asking me a question. Reject any sentence that requires context only I have — either add the context or change the sentence. Output the SOP as a single document, 5-10 pages max — longer than that and no one reads it. The test of the SOP is not how thorough it is. The test is whether a competent stranger could run a week from it.”
10. The handoff readiness check — what’s still founder-only, and what does it take to lift it off me. “List every task inside the M9 system that currently only the founder can do. For each: the reason it’s founder-only right now (genuinely requires the founder’s judgement / requires the founder’s voice / requires the founder’s network / just hasn’t been documented yet — only the last is a real constraint), the cost of keeping it founder-only at 5x current volume (in hours per week, in opportunity cost, in burnout risk), the lift-off path (what specifically would have to be built — SOP, training video, a defined judgement rubric, a named handoff candidate — for someone-not-the-founder to do this well, not just adequately), and the realistic timeline to lift it off (3 weeks / 3 months / never). Output as a 4-column table. The ‘never’ rows are the founder’s actual job — the things only they can do, that the business is built around. Everything else is a delegation queue for M11. The honest count of how many tasks are ‘never’ versus ‘just not yet documented’ is the most important number in this whole module — most founders think 80% is ‘never’; the real number after honest review is closer to 20%. The other 60% is what M11 will lift off.”