The founder weekly review: a 60-minute Friday template that actually sticks

Why a weekly review beats a daily check and a monthly report

Daily is too often. Most numbers that matter to a company of five to fifteen people barely move in a day, and you end up reacting to noise. Monthly is too rare: a deal that went quiet in week one is dead by week four, and a teammate who was struggling for a month has usually already decided to leave.

A week is the smallest unit in which revenue, hiring and shipping all show a signal. It is also the natural rhythm of the rest of the team's work: cycles end, invoices go out, candidates reply.

The format borrows one idea from David Allen's Getting Things Done, which prescribes a weekly review to get "clear, current and creative" over every open loop. The founder version narrows that to the company's loops rather than your personal ones, and it adds a fixed agenda, because an open-ended review is the first thing cut when Friday gets busy.

The 60-minute agenda

Block the hour in your calendar as a recurring event with a hard stop. Keep the doc open in a second window. Timings below are what we use; the order matters more than the minutes.

If you consistently run over, the fix is not a longer block. It is a smaller set of numbers, or a pipeline that needs pruning.

Section by section: what to write down

Numbers

Pick four to six figures and keep them for a quarter at a time. For a software company that usually means monthly recurring revenue, cash balance and runway in months, new customers this week, churned customers this week, and one usage metric that predicts retention (weekly active teams, runs started, seats in use). For an agency it is billable hours sold against capacity, invoices outstanding over 30 days, and cash.

Write the number, the delta from last week, and one line of cause if the delta is notable. Resist adding a seventh metric. If you want to track something new, drop one.

Pipeline

Walk every open deal that could close this quarter. For each: stage, last touch date, next action, and who owns the next action. The deals that hurt are the ones nobody touched this week; mark them and decide whether to chase, park, or close-lost. Close-lost is a result, not a failure. A pipeline of twenty stale deals is worse than a pipeline of six honest ones.

Also note inbound you have not replied to and discovery calls booked for next week, so Monday morning starts with the calendar already understood.

People

This is the section founders skip, and it is the one that costs most when skipped. For each person: are they blocked on you? Are they carrying more than their share? Did they do something this week that deserves a public thank you on Monday? Who is on leave next week and does their work have cover?

Keep this to one or two lines per person. If a line turns into a paragraph, that is a 1:1 to schedule, not a note to write.

Product

What shipped this week, in customer terms, not ticket numbers. What slipped, and whether the slip is a scoping problem or a capacity problem. What customers said, quoted directly from support or sales calls. If you run cycles, note the burndown against the goal and whether the rollover into next cycle is reasonable or a sign the cycle was overloaded.

Next week

Choose three priorities. Three, not five. Each one should be a thing you can say was done or not done on the following Friday. "Improve onboarding" is not a priority; "ship the new invite flow to all workspaces" is. One of the three should usually be a pipeline action, because sales is the thing founders defer when the product is more interesting.

The template

Copy this into a page and duplicate it each week. We keep all weeks in one nested page tree, newest on top, so the history is one scroll away.

Weekly review — week of 2026-10-26

== Numbers
| Metric | This week | Last week | Note |
|---|---|---|---|
| MRR | | | |
| Cash / runway | | | |
| New customers | | | |
| Churned | | | |
| Weekly active teams | | | |

== Pipeline
| Deal | Stage | Last touch | Next action | Owner |
|---|---|---|---|---|

Stale (no touch this week):
Inbound unanswered:
Discovery calls next week:

== People
- Name — blocked / overloaded / thank publicly / on leave

== Product
Shipped:
Slipped (and why):
Customers said:
Cycle burndown vs goal:

== Next week's three
1.
2.
3.

== Decisions I made this week
-

== Parked (not this week, not forgotten)
-

The "Decisions" section is the one people thank us for later. Six months on, when someone asks why the pricing page lost the free plan, the answer is in week 37 rather than in nobody's memory.

Where the data should come from

The hour only works if the inputs are already in one place. If you spend the first twenty minutes collecting numbers from six tabs, the review becomes a chore, and chores stop.

Three ways to arrange it, in rough order of effort:

1. A notebook and a spreadsheet. Honestly fine for a company of two or three. The spreadsheet has the five numbers; the notebook has the rest. The cost is that nothing is linked, so "which deal was that" means searching email.
2. Separate tools with a weekly export. CRM for deals, tracker for product, HR tool for leave. You open each one in turn. Works, but the people section always ends up thinnest because the HR tool is the one you open least.
3. One workspace. Deals, issues, cycles, leave and goals in the same system, so the review is reading rather than gathering.

Atrix is built for the third option and is what we use ourselves, so this is a biased recommendation with its limits stated. The workspace brief is a generated digest of what needs attention today across deals, issues, hiring and leave; the same data is exposed through the MCP server as attention_today and workspace_brief, so you can have an assistant draft the Numbers and Pipeline sections before you sit down. Deals and goals with key results sit in the same workspace as the issue tracker and cycles. The limits: Atrix has no revenue analytics of its own, so MRR and cash still come from Stripe and your bank; deal values are permission-gated, so whoever runs the review needs the crm.value.view permission; and there is no free plan, so it only makes sense if the rest of the team is in it too.

You can see how founders use the setup on the founders page, and the CRM and project management pages describe the pipeline and cycle views the review reads from.

Five mistakes that kill the weekly review

1. Letting it float. A review with no calendar block becomes "when I have time", which is never. Recurring event, hard stop, phone face down.
2. Writing a report instead of a review. The doc is for you and, at most, a co-founder. If it starts being written for investors it will become polished and useless. Keep a separate monthly investor update if you need one.
3. Tracking too many numbers. Four to six. More than that and you will stop noticing when one moves.
4. Skipping People when the week was busy. The busy weeks are exactly when someone is overloaded.
5. Five priorities. Three. If everything is a priority, Monday is a list, not a plan.

FAQ

How long should a founder weekly review take?

Sixty minutes with a hard stop. If it regularly runs to ninety, the inputs are not ready; fix the gathering, not the block. Under thirty minutes usually means the pipeline or people sections are being skimmed.

Friday or Monday?

Friday afternoon, because the week's data is complete and the output is a plan Monday can start on. Monday reviews turn into planning without reflection, and they collide with the team's first meeting of the week. Some founders prefer Sunday evening; the cost is that work starts leaking into the weekend.

Should my co-founder do it with me?

Do it separately, then compare the Next Week sections for fifteen minutes. Two people writing one doc together tend to negotiate rather than observe. The comparison is where disagreements about priority surface, which is the useful part.

What is the difference between this and a weekly team update?

The team update is written for the team and shared; this is written for you and kept private or shared only with a co-founder. The team update is mostly output; the review is mostly judgement. Many founders write the team update straight after the review, which is a good use of the material.

Can I run it in a plain notebook?

Yes, and for a company of two or three it is probably the right call. The template above works on paper. The reason to move it into software is history and linking: being able to search for a deal name across forty weeks of reviews, or click from "slipped" to the actual issue.

What numbers should a pre-revenue founder review?

Replace MRR and churn with the leading indicators of whatever you are trying to prove: sign-ups, activation rate, weekly active users, discovery calls completed, and cash and runway, which apply to everyone. Keep it to the same four to six.

Next step

If your deals, issues and people are already in one place, the review is an hour of reading. If they are not, start with the template above in whatever doc tool you have, and look at the founders page for how the workspace brief pulls the same sections together automatically. The CRM is where the Pipeline section comes from.