The Growth Cockpit: The Monday Memo That Replaces the Growth Meeting

The meeting that reads a dashboard out loud

It is Monday at 9:30. Eight people are on a call, one of them shares a screen, and for forty minutes the team reads out numbers that sat in a dashboard all weekend.

Clicks are up. Cost per lead is down a little. Nobody can say why, so the call ends with a promise to keep watching, which is the one thing the dashboard was already doing.

The fix is the sixth of the six systems in what a marketing engineer builds: a growth cockpit. It is a one-page memo that arrives before the meeting would have started, and it says what moved, why, and what to do next.

The dashboard was never the problem. Nobody wrote down what it meant.

This is not a rare kind of meeting. A Harvard Business Review study found executives spend nearly 23 hours a week in meetings, up from fewer than 10 in the 1960s, and the weekly growth review is one of the easiest to replace because most of it is reading.

Greg Isenberg describes the cockpit in his episode on the marketing engineer role as a weekly view of what is moving and what to act on. It covers which content worked, which campaigns started real conversations, which objection keeps coming back, which tests won, and what competitors did. His bar for a good one is simple: an executive should want to wake up to it.

Below you get the memo template, the inputs, a worked example, and a one-day build plan. By the end you will know whether your Monday meeting needs to exist.

What the memo says, line by line

A good memo is short enough to read on a phone in two minutes. The template below has ten lines, and the order matters: verdict first, evidence second, decisions last.

Line 1 is the verdict, one sentence a CEO could act on without reading further. Lines 2 to 6 are the evidence: the three numbers that matter, the tests that finished, what customers said, what moved outside, and what your own team changed.

Lines 7 and 8 are the decisions: the calls, each with an owner, and anything that needs a yes before it spends money or reaches a customer. Line 9 says whether the data can be trusted. Line 10 grades last week's calls.

Two rules keep the numbers honest. Every number shows this week, last week and the four-week average, so a normal wobble gets labelled noise instead of news. And line 3 only reports tests that reached the sample size you set before they started.

That second rule matters more than it looks. Evan Miller showed that if you stop a test the moment it looks significant, a change that does nothing will look like a winner 26.1 percent of the time, not the 5 percent you think. A memo that reports every running test is a memo that reports coin flips.

Line 6 is the one teams skip, and it explains everything else. If nobody wrote down that the landing page headline changed on Tuesday, nobody can tell you why Wednesday looked different.

Change, Cause, Call: the rule every line follows

Most weekly reports fail the same way. They list numbers and stop.

Every line in a cockpit memo carries three parts, and we call the rule Change, Cause, Call.

The change is what moved, by how much, and against what. The cause is the most likely reason, with a receipt: a link, a quote or a log entry. The call is keep, kill or test, with an owner.

Here is the difference in one line. A report says: "Cost per lead rose 22 percent." A cockpit says: "Cost per lead rose 22 percent, from $41 to $50, after the dispatch ads started reaching the same people five times a week; pause them and move the budget to the replacement angle, owner Sam."

The cause is where AI writers get dangerous. A model asked to explain a number will always produce an explanation, and it will sound sure of itself.

Statisticians named this trap long ago. Twyman's law says "any figure that looks interesting or different is usually wrong," most often because the measurement broke, not because the world changed. So the cockpit checks data health before it writes a single cause, and a cause with no receipt gets cut.

No receipt, no cause.

The inputs, and where each one comes from

A cockpit is only as good as what it reads. Most companies already have every input; they just live in seven browser tabs.

Search first. Google's Search Console Performance report gives clicks, impressions, click-through rate and average position, and the Search Analytics API hands the same numbers to a script. Google notes that the newest data can be preliminary and may still change, which is why line 9 exists.

Site behaviour comes from the Google Analytics Data API, which returns GA4 report data to a script. For ads, Meta's Insights API returns performance for campaigns, ad sets and ads, and Google Ads can email any statistics table as a scheduled report if you would rather not touch an API yet.

Revenue comes from the CRM: booked calls, deals, money. If you sell on a call, the four rates in Book-a-Call Math are the spine of line 2, because they tell you which layer owns a bad week.

Customer signal is the weekly file your customer truth system writes from calls, tickets and reviews. Your own changes go in a plain log of what shipped, with dates. Your tests go in a log of what is running, the planned sample, and the stop date.

Read the ad numbers with care, because platforms count differently. Reading Ad Data walks through which number to trust at each step from impression to payment, and the cockpit should read them in the same order.

Give the agent read access only. A memo writer has no reason to touch a budget, and keeping it out of the ad account removes a whole class of mistakes. If your CRM and ad platforms disagree on what a lead even is, fix that before you build anything; it is the kind of problem our CRM and RevOps work exists to solve.

The HVAC example, worked through

Isenberg's example is a software company that sells to commercial HVAC contractors: dispatch, service calls, maintenance contracts. The buyer is an owner with a messy operation and very specific words for what hurts.

His sample cockpit line is the kind you want. In it, the angle about lost replacement revenue loses to the dispatch angle on clicks and beats it on demos, two times the requests, from owners who run 20 or more technicians.

The figure below builds a full memo around that one line. The numbers are invented to show the shape; the logic is the point.

Read the call in line 7. The money moves toward the angle with fewer clicks, because clicks are activity and owner demos are revenue.

A dashboard would have crowned the dispatch ad. It had the bigger bar.

Look at line 4 too. Four of nine sales calls mentioned quotes that were never sent after the technician left, and that came from the customer truth file, not the ad account. When the market signal and the ad result point the same way, the call gets easy.

Build it in a day

The first version takes one working day if your data already lives in the tools above. The figure shows the order we would build it in.

Start with one number. Pick the one the business already runs on, owner demos or booked calls or paid orders, and write down its last four weeks by hand.

Then write the agent a job spec, not a prompt. Eight lines cover it: the job, inputs, trigger, limits, output, examples of good, what needs approval, and the metric; the template is in How to Write a Job Spec for an AI Agent.

Backtest before you schedule. Run the agent on last week, a week you already know, and check every claim against its source. Count the wrong ones, fix the spec, and run it again until the count is zero.

Scheduling is the easy part now. Claude Code routines run a saved prompt against your repo on a schedule in Anthropic's cloud, and they keep running when your laptop is closed. A plain cron job on a small server does the same thing.

If you want a version by lunch, start inside your analytics tool. PostHog's prompt subscriptions write an AI report from a plain-English prompt on a daily, weekly or monthly schedule and send it to email or Slack. It only sees PostHog data, so treat it as line 2 of the memo, not the whole memo.

If you would rather have it built, the cockpit is one of the six systems in our marketing engineering engagements. It is often a sensible first one, because its first month shows where the other five belong.

Approval and memory: why the memo gets smarter

A person approves the memo before it goes out. Not because the agent is bad, but because line 8 asks for money and line 7 assigns work, and both need a name on them.

The approver's edits are the most valuable data in the system. Every time they cut a cause or fix a number, that correction goes into the agent's rules file, so the same mistake does not come back next Monday.

Claude Code reads its CLAUDE.md memory file at the start of every session, and Anthropic advises keeping each file under 200 lines with rules concrete enough to check. "Ignore Sunday search data, it is preliminary" works. "Be careful with data" does not.

Then keep a decision log. Every call from line 7 goes into a file with its owner, target and date, and next Monday line 10 reads that file and grades each call.

That loop turns a report into a system. A report tells you what happened. A cockpit tells you whether your last decision was right, and after a quarter you have twelve weeks of graded calls instead of twelve weeks of slides.

The rules file and the decision log belong in your growth repo, next to the customer truth file and the job specs. A chat window forgets. A repo does not.

We run our own operation on the same pattern. Memory lives in a vector database that agents search before writing and update after, and our article library cannot publish until scripts confirm every citation loads and no paragraph runs past three sentences.

Our AI search tracking read 409 AI answers on September 22, 2026, and Reddit sat behind just 1.0 percent of 4,243 citations. That finding had all three parts of a cockpit line: a change from what the big public studies report, a cause we could check, and a call about where we write. The full run is in What AI engines actually cite.

"We already have a dashboard"

Good. Keep it. The cockpit reads the dashboard so that nobody has to read it aloud.

Here is what the critics of AI reporting get right. An agent that writes causes will sometimes write fiction, and a memo nobody checks becomes one more email nobody opens.

Both are design problems with known fixes: the receipts rule, the data health line, and a named approver. If you cannot name the approver, do not build the cockpit yet.

The second honest limit is volume. If you get a handful of leads a week, most weekly movement is noise, so run the same memo every two or four weeks and compare like with like.

And the memo does not abolish meetings. Amazon, which replaced slide decks with six-page memos, still meets; the room reads the memo in silence first, then talks. Jeff Bezos also wrote that great memos are rewritten and set aside for days, a reminder that a one-page Monday memo is a different tool: a weekly scan, not a strategy paper.

Your Monday call can survive. It just starts after everyone has read line 1, and it ends when line 8 has an answer.

What to read next, and why

The Creative Testing Engine [system]. The cockpit grades tests; this is the system that makes them. Read it if line 3 is empty most weeks.

How to Evaluate a Marketing Engineer's Work [scorecard]. Six numbers by system and what good looks like at 30, 60 and 90 days. It is line 2 of the memo, chosen properly.

The First 90 Days With a Marketing Engineer [plan]. The one-system rule, applied. A good argument for building the cockpit before anything else.

Read 'Results', Not 'Leads' [mistake]. The reporting error that makes a working Meta campaign look broken. Fix it before Meta numbers go anywhere near your memo.

So the simple takeaway is this: a Monday number without a cause and a call is decoration.