What I want from a weekly founder review is a clearer next decision, not a longer account of how busy the week felt. Shipping, conversations and research matter when they change what can be understood or done. A review should connect those activities to evidence, commitments and the capacity available for the next period.
This is a review structure I propose as a founder and project manager. It is not a report of an established weekly routine or measured results across the projects on this site.
Begin with promises that remain open
List commitments to users, customers, collaborators and the product itself. Which were completed, which changed and which need a new owner or explanation? Starting here prevents a review from focusing only on exciting new work while existing responsibilities become invisible.
Keep completion evidence concrete. A page deployed, a decision recorded or a task accepted is different from “almost done.” Where the outcome is partial, describe what remains and what blocks it. That makes next week’s capacity more realistic.
Separate activity from changed knowledge
| Review lens | Question |
|---|---|
| Delivery | What became usable or complete? |
| Evidence | What did we observe that we did not know before? |
| Decision | Which choice became clearer or changed? |
| Reliability | What needs repair or ongoing attention? |
| Capacity | What work can actually be supported next? |
| Stop list | What should no longer consume attention? |
A week can contain valuable learning without a large release. It can also contain many completed tasks without reducing the central uncertainty. The review should make both situations visible without turning either into a slogan.
Revisit one important assumption
Choose the assumption most relevant to the next investment of time. What evidence supports it, what contradicts it and what remains unknown? If the same question has appeared for several reviews, ask whether the current method can actually answer it.
For example, repeated interest in a concept may not resolve whether a user can complete the proposed workflow. Another landing page revision might add little information. A small task test could be the more useful next step. The content-to-workflow guide illustrates this distinction.
Make project status serve a decision
A list of projects with green, amber or red labels can be convenient but vague. Each active project should have a current question, a next evidence-producing action and a clear scope. A paused item should have a reopening condition rather than an indefinite reminder to worry about it.
Do not assume every project deserves a new task each week. Some work may need maintenance, some observation and some deliberate inactivity. The decision is about the best use of current capacity, not about making every row look active.
End with a limited set of commitments
Choose the work that matters most and identify what will not be attempted. Include review and repair time rather than filling the entire period with new production. Where a task depends on someone else, separate the request from work that can proceed independently.
Each commitment should have an observable completion condition. “Improve onboarding” is less useful than completing a defined task review and deciding which barrier to fix. The reversible product decision log provides a way to preserve the reasoning behind those choices.
Keep the review short enough to repeat
The record should be detailed enough to explain decisions later, but not so elaborate that maintaining it becomes another project. Preserve the previous review and add new observations rather than rewriting history to match the latest result.
The shipping and learning article expands the evidence distinction. A good founder review leaves fewer ambiguous commitments and a more defensible allocation of attention. Its value is in what the next week does differently, not in how polished the review document looks.