How to Run a Weekly Review Alone: Metrics and Questions

Four required columns, one optional column, one row per metric per week.

That is the whole artifact. It fits on a screen, it copies forward in seconds, and it forces the four moves a review exists for: face the gap, read the numbers, decide, commit.

Two formatting rules make it survive contact with a busy week. First, write values in the unit you would say out loud ("6.5 months of runway", not "198 days"), because you are reading this at 4pm on a Friday, not building a board deck. Second, never leave a cell blank to mean zero. Blank means not measured, and a not-measured metric is a decision waiting to happen.

David Allen's original weekly review splits into get clear, get current, and get creative the official GTD weekly review checklist. For a solo founder the "get clear" pass matters most, because there is no colleague collecting the loose commitments for you. The log is where they land.

DATE        METRIC              VALUE       DELTA     DECISION
2026-03-06  cash_runway_weeks   41          -1        none
2026-03-06  pipeline_weighted   84,000      +12,000   push 2 stale deals to closed-lost by 03-13
2026-03-06  shipped_count       2           -1        cap WIP at 2 items until 03-20
2026-03-06  commitments_kept    7/11        -2        stop promising dates on calls; quote ranges

Read that block again. Nothing in it is a feeling. Every row has a number and a consequence, and the consequences are the start of next week's task list.

The timing matters more than the content. Put the review at the end of the working day, not the start, so it can trigger follow-up messages while people are still reachable; David Allen recommends early Friday afternoon for exactly that reason David Allen's weekly review. Friday also keeps the review out of the maker's deep-work block. Paul Graham's distinction is that makers need half-day units and a single meeting can split an afternoon into two unusable pieces Maker's Schedule, Manager's Schedule, and a practitioner adaptation of that essay recommends keeping Friday clear of meetings for reflection and planning the next week Scrum.org on maker and manager schedules.

Here is the agenda, with minutes that add to 45.

The five questions, asked in this order:

1. What moved, and by how much? Answer with the delta only. This is where most reviews stop, and stopping here turns the log into a dashboard nobody acts on.
2. Why did it move? Name the cause with evidence, not a vibe. "Four of five new accounts stalled at import" is evidence; "users seem confused" is not the worked founder review example.
3. What did I promise, and did I keep it? Compare commitments made last week against commitments kept. This is the only number in the log that measures you rather than the market.
4. What am I avoiding? Name the task that keeps rolling forward without a decision. A blocker with no owner and no next action is a complaint and it will roll over again.
5. What is the one thing next week must produce? One outcome, then the three tasks that produce it. Not five priorities.

Step 3 deserves emphasis. When you work alone, nobody notices a promise that quietly lapsed. Counting commitments kept out of commitments made, every week, is the cheapest accountability system available, and it costs one line in the log.

A practical note on measuring that counter honestly: define what counts. A commitment is a specific deliverable promised to a named person with a date attached, made during the week. "I'll look into it" is not a commitment. "I'll send the revised proposal by Thursday" is.

The four metrics are chosen because each one fails silently and each one answers a different question. Cash answers "how long can I keep going", pipeline answers "is revenue coming", shipped output answers "am I converting time into progress", and commitments kept answers "am I trustworthy as an operator".

A worked example, using round numbers, shows the decision rule in action. Suppose runway was 42 weeks last review and 41 this week, a delta of -1. Suppose weighted pipeline rose by 12,000 but two of the largest deals have not changed stage in three weeks. Suppose you planned three shipped items and shipped two. Suppose you made 11 commitments and kept 7.

Three of the four numbers moved in an unwelcome direction, but only two generate action. Runway falling by one week per week is expected until revenue rises, so no decision is needed yet; the trigger is the floor you set in advance, for example 26 weeks, at which point the plan changes. The stale deals generate a decision: move them to closed-lost by a named date, which is what the log row above does. The commitments ratio of 7 out of 11 generates a second decision: stop quoting specific dates on calls and quote ranges until the delivery record improves.

Note what did not happen. You did not write a paragraph about how the week felt. You converted two numbers into two dated tasks and left two alone because they had not crossed a threshold. The Eisenhower framing helps here: the discipline is separating what is urgent from what is important, and the threshold is what stops every number from feeling urgent the Eisenhower Matrix explained. Urgency has a documented pull on attention, and people reliably pick time-sensitive tasks over higher-value ones when both are on the list Todoist on the mere-urgency effect.

Set the thresholds once, in writing, at the top of the log. Then the review is mostly reading, not agonizing.

The review is wasted if it ends with observations. The end state is three to five tasks, each with a check date that falls on or before the next review, so the following Friday can grade them.

A simple closing workflow keeps this honest. For each decision from the review, write the task in the imperative, name the single first physical action, and attach the date you will verify it. "Push stale deals to closed-lost" becomes "Email both contacts to confirm no decision, by Wednesday". Vague tasks are the reason plans never complete. One published template arrives at the same shape from the other direction: a single priority for the week plus three supporting tasks, chosen from evidence rather than from whichever item feels loudest on Friday the founder weekly review template.

Let the four numbers carry most of the weight. A review that opens with whatever felt loudest during the week recreates the urgency trap in miniature; a review that opens with the delta column cannot, because the numbers were chosen in a calm moment and they do not change week to week. David Allen's advice is the same in spirit: review the lists, the calendar, and the projects, and let the triggers surface the actions rather than inventing them fresh David Allen's personal weekly review.

Two failure patterns to watch. The first is a plan that always completes, which means the plan was too small and the review is teaching you nothing. The second is a plan that never completes, which means you are writing fiction on Friday and reading it on Monday the founder weekly review template. Both are visible in one metric: shipped count against planned count. If the ratio is consistently very high or very low, resize the plan rather than working harder.

The other habit worth building into the log is the decision record. When you make a call that you might reverse (a pricing change, dropping a channel, a partnership), write what you decided, the evidence you had, and what would make you revisit it. The Techstars operating-system advice makes the case directly: a decision log forces you to separate facts from assumptions, and it lets future advisors or hires see how the company got where it is Techstars recommendations for solo operators. It costs one line in the same document.

The most common reason weekly reviews die is scope creep. Someone adds a competitor tracker, a journaling section, a mood score, and eleven metrics, and within a month the review has become the thing being avoided.

Hold the line with three rules.

One page per week, no exceptions. If a metric cannot change a decision, it does not get a row. The Qlik distinction is useful: a KPI measures progress toward a strategic goal, while a supporting metric measures a process that contributes to it Qlik's KPI examples. Your four numbers are KPIs. Everything else is supporting material that goes somewhere else.

One source of truth per number. Decide at setup which system produces each value (bank balance for cash, CRM for pipeline, your task tool for shipped items and commitments) and never re-derive it from memory. If a source takes more than two minutes to read, automate the read, not the judgment.

Same time, same place, same steps. The routine itself becomes the trigger for the mindset, which is why the when and where of the review matters as much as the what a GTD weekly review guide.

The log then does something the review alone cannot: it becomes the institutional memory of a one-person company. After a quarter you have 13 rows per metric and a visible trend, which is the difference between knowing your runway is shrinking and remembering that it has shrunk for eleven straight weeks.

If the numbers themselves feel like the hard part, that is usually a model-access problem rather than an analysis problem. Sending weekly figures to a model that can read spreadsheets, images, and text through one interface takes the copy-paste out of step two, and Quanta Inference exposes text, image, video, audio, and embedding models behind one OpenAI-compatible key, prepaid in US dollars.