A DTC skincare brand we worked with last fall had run over 200 experiments across two years. The history lived in a single Google Sheet with 47 tabs — one per testing cycle, indexed only by month. When their experienced media buyer left, the new hire opened the sheet on day one and couldn't answer the most basic question I'd ever ask a buyer: what's worked, what hasn't, and what should I try first?
Two years of testing. A 47-tab paper trail. Zero usable knowledge.
This is the closing post in the Growth Engine series. Part one was about testing as learning. Part two was about scaling as discipline. Part three was about the loop that captures everything those two cycles produce. This post is about the artifact that loop produces — the document that actually runs the team.
Data isn't knowledge
The 47-tab spreadsheet had data. Every test was logged. Hooks, audiences, results, dates. What it didn't have was a way to retrieve any of that knowledge when it mattered.
Insights existed — they were just buried under 200 rows, indexed by chronology rather than theme. To answer "what hooks work for cold audiences," the new buyer would have had to read every entry, manually categorise it, and synthesise. Three days of work. That's not knowledge retrieval; that's archaeology.
Most teams optimise for documentation. They write everything down. The artifact that actually compounds is optimised for retrieval.
Artifact vs experiment log — not the same thing
The experiment log (from part three of this series) is chronological. Every test gets an entry, in order. It's the source data.
The Growth Learnings Artifact is thematic. Insights from the log get organised by what they're insights about. Audience truths in one place. Hook patterns in another. Format learnings in another. The log captures moments; the artifact captures patterns.
Both are necessary. The log without the artifact is a graveyard. The artifact without the log has no source of truth to update from.
The ten sections of the artifact
The structure we run on every account:
- 1. Audience & ICP learnings. Which segments convert and why. Demographic + psychographic patterns. Lookalike performance ranked by LTV, not just CPA.
- 2. Messaging & hook learnings. Which messages land at which audience temperature. Winning opening lines, tonal observations, what consistently fails.
- 3. Offer learnings. Discount structures, bundles, urgency tactics, price sensitivity by segment. Often: free-shipping thresholds outperform percentage discounts.
- 4. Creative & format learnings. Video vs static, optimal lengths, UGC vs brand, fatigue timelines per format.
- 5. Funnel & landing-page learnings. Structures that convert. Above-the-fold elements. Form length impact. Mobile vs desktop deltas.
- 6. Platform-specific learnings. Meta vs TikTok vs Google. The carousels that succeed on Meta and consistently bomb on TikTok — documented so the next operator doesn't relearn it.
- 7. Scaling learnings. Budget thresholds where efficiency breaks. Audience size requirements. Signals that predict scaling success vs failure.
- 8. The graveyard. Anti-patterns. Expensive mistakes. Formatted as: anti-pattern → consequence → evidence → rule.
- 9. Quarterly synthesis. Every 90 days, 5–7 bullets that capture the strategic implications of everything above. Not results; principles.
- 10. The current playbook. The actionable SOP. Audience, hook style, format, offer, landing page, budget posture, scaling triggers, refresh cadence. Written so the new hire on day one can run the account.
Section ten is the test of whether the rest of the artifact works. If a senior operator can't pick up section ten and run the account, the other nine sections aren't pulling their weight.
How Claude + the Meta MCP server keeps the artifact alive · the April 2026 workflow
The biggest enemy of the artifact isn't structure. It's staleness. The team builds it once, uses it for three weeks, gets busy, and the doc decays. Six months later, the artifact and the actual account have diverged so far that nobody trusts the artifact anymore.
This is where the 2026 stack genuinely changes the game. The combination that works for us:
- Claude Desktop running the latest Claude model (Opus or Sonnet, depending on the analysis depth)
- The Meta Ads MCP server (community-maintained, runs locally, read-only token to your ad account)
- The Notion MCP server if your artifact lives in Notion, or the equivalent for Google Docs / Coda / Linear
The recurring workflow we run is genuinely simple:
- Weekly · insight extraction. Friday afternoon prompt to Claude: "Look at every experiment that ran on the Meta account this week. For each one, compare against the section of the artifact it relates to (Audience, Hook, Format, Funnel). Tell me where the new data confirms what's in the artifact, where it contradicts, and where it surfaces something we don't have a pattern for yet."
- Operator reviews drafts. Claude proposes edits to the artifact — new bullets to add, lines to update, contradictions to flag. The human approves, edits, or rejects each. Maybe 15 minutes.
- Quarterly · full synthesis. Once every 90 days, the bigger prompt: "Review the last 90 days of experiments. Draft the quarterly synthesis — 5–7 principle-level bullets — and flag anything in the artifact's current playbook that should change based on what we've learned." The operator then runs that draft past the team, edits it, and commits it.
What changes operationally: the artifact stops being a document somebody is supposed to maintain on top of their actual job. It becomes the natural output of a 15-minute Friday ritual. The retrieval value compounds because the artifact actually stays current.
Two notes on safety, because we get asked:
- Read-only tokens only. Both the Meta MCP server and any analytics MCPs you connect should use read-only credentials. The model can fetch; it cannot launch, pause, or edit campaigns. The downside risk stays small.
- Human approval before writes. Even with the Notion MCP connected, we never let Claude write to the artifact unsupervised. The draft-then-approve cycle keeps the institutional voice consistent and prevents drift.
What the artifact unlocks
When the artifact works and stays current, three things change:
- New hires ramp in days. The artifact is day-one reading. By end of week one, they can run weekly experiments.
- Past mistakes don't repeat. Before launching a new test, the operator searches the artifact. Most "new" ideas have been tried before. Knowing how it went last time changes how this one gets designed.
- Strategy becomes evidence-based. "We should test X" stops being an opinion debate and starts being a reference to past patterns. Disagreements get resolved by going to the artifact, not by seniority.
The iteration that got us here
I'll spare you the version history but: this is iteration four. The first artifact was a 47-page Google Doc. Unsearchable. The second was an overly-engineered Notion database with 30 properties per entry. The team gave up filling it in. The third was somewhere in between. This version — ten sections, retrieval-first, maintained by a 15-minute weekly Claude ritual — is the one we'd ship to any team.
The principle underneath all of it: systems must optimise for retrieval value, not documentation burden. A document nobody opens after week one isn't an artifact — it's a graveyard.
Closing the series
The Growth Engine is four moving parts:
- Test with discipline. The ad is a byproduct; the learning is the asset.
- Scale with discipline. Aggressive but trigger-driven beats cautious every time.
- Capture the loop. Every test should compound; most don't.
- Synthesise into an artifact. This post.
The teams that compound run all four. The teams that don't, ship campaigns hoping the next one matches the last. Two paths. Same budgets. Wildly different five-year outcomes. The artifact is your new hire's day-one reading. Build it.
