Founders of small brands ask the same question all week, in different words. "Where are we on the reorder?" "Did the developer finish?" "Is anything on fire?"
Each question is fair. Together they turn the operations manager into a help desk and the founder into a project manager.
The Friday founder update is the fix I use. One written message, the same four headings every week, sent at the same time. This post shows how I'd put it together and what I'd measure to know it is working.
Table of contents
The problem: status lives in people's heads
In most small brands there is no single place that says how the week went. The information exists, but it is spread across Slack threads, a task tool, two spreadsheets and someone's memory.
So founders pull it out one question at a time. Each answer is accurate for about a day.
The bigger cost is decisions. A question that needs a founder's yes or no gets asked in passing, buried under other messages, and comes back a week later as a delay.
And bad news travels slowly. Nobody wants to interrupt a founder to say a purchase order might slip, so they hear about it when it has slipped.
How the system is put together
It has five parts: where it lives, the four headings, the five counts, the weekly steps, and who does what.
Part 1: one channel, one message
The update goes in Slack, in the founders' channel, as a single message. Not a meeting, not a slide deck, not a dashboard.
This is the Friday step of the weekly rhythm in my operations setup plan. It uses the tools the brand already has.
After posting, I'd pin it. Slack's help pages say pinned messages appear in the channel's Pins tab, so the latest update is always one click away and last week's can be unpinned.
Part 2: four headings, always in the same order
Done. What was finished this week. Outcomes, not activity. "PO for the winter restock confirmed, ships on the 28th" beats "followed up with the factory".
Next. What happens next week, with an owner against each item. This becomes the draft of Monday's priorities post.
Blocked. What is stuck, who or what it is waiting on, and since when.
Decisions needed. Each one written so it can be answered in a line: the question, the options, what each costs, my recommendation, and the date I need an answer by.
The shape is not my invention. Asana's guide to project status reports describes the same bones: a brief summary, the blockers with how they will be resolved, and next steps. It also suggests weekly reports for fast-moving work, which an ecommerce brand is.
I keep the fourth heading separate because it is the only part that asks the founder to do something. If it sits inside "Blocked", it gets read as information.
Part 3: five counts at the top
Before the headings, five numbers. They come straight from the targets in the setup plan.
Orders unshipped past 48 hours with no named owner. Stock problems that had no alert first. Purchase order dates missed without a warning. SOP pages past their review date. Tasks idle for more than two days.
Each is a count, and the aim for each is zero. A founder can read that line in ten seconds and know whether the rest needs a close look.
Asana's guide suggests a simple colour for overall health: green for on track, yellow for at risk, red for off track. I'd use one colour for the whole week and let the five counts explain it.
Part 4: the weekly steps
All week: the inputs fill themselves. Problem orders land in the exceptions tracker. Inventory alerts and purchase order reminders are logged. Tasks are updated in the task tool as they move. Nothing extra is written for the update.
Thursday afternoon: pull the five counts from the trackers and list anything open more than two days.
Friday morning: write the update from the trackers, not from memory. Link to the tracker row or task for anything a founder might want to open, and keep the message itself short.
Friday, same time every week: send it. Slack's help pages describe how to schedule a message to send later, so I'd write it early and schedule it for the agreed time. Consistency matters more than the hour you pick.
By Monday: founders reply in the thread under each decision. Answers go into the decisions channel so there is a record, and the "Next" list becomes Monday's priorities post.
Part 5: what is automatic and what a person does
The data collection is automatic. In the setup plan, problem orders reach the tracker through Shopify Flow, and stock and PO reminders run on a schedule. I broke those down in the order-to-fulfillment system and the days-of-cover alert.
The writing is a person's job. Deciding what matters, what to leave out and what to recommend is the whole value of the update.
The plan allows an AI tool to prepare a first draft from the trackers, with the founders' approval, and with every output checked by a person before it is used. I'd treat that as a time-saver for the "Done" list, never for the decisions.
Ownership is simple. The operations manager owns the update and its accuracy. Founders own the answers, and the deadline on each decision is theirs to meet or move.
What it solves
The status ping. Founders know when the full picture arrives, so most mid-week questions can wait for it.
Slow decisions. Every decision has a written question, options, costs and a date. It is hard to lose and easy to answer.
Late bad news. "Blocked" is a standing heading. Reporting a risk is filling in a section, not raising an alarm.
No record. Twelve weeks of updates is a plain history of what was done, what slipped and what was decided. That is useful for a new hire, and for the founder's own planning.
Meetings held just to catch up. If a call is still needed, it starts from the update and goes straight to the open decisions.
The effect on the business, and how to measure it
I'm not going to quote results. This is a working method, not a case study, and I don't publish numbers I can't show.
The target written into the setup plan is that nothing sits for more than two days: stuck work gets chased, then escalated. The Friday update is where that rule becomes visible. That is a target, not a result.
Here is what I'd write down for two weeks before starting, and compare after eight.
Status questions. Count the mid-week "where are we on" messages from founders. This is the clearest sign of whether the update is trusted.
Decision turnaround. Days between a decision being asked for and answered. Then count how many are answered by the date in the update.
Decisions carried over. How many appear in two updates running. More than one or two means the options are unclear or the founder needs a short call.
Age of blocked items. How long the oldest item under "Blocked" has been there.
The five counts. They should trend toward zero. If one doesn't, it tells you which workflow to look at.
Weeks sent on time. If the update slips, everything above slips with it.
If the questions don't drop after a few weeks, I'd look at the update before the founder. It is probably too long, or it is missing the thing they actually worry about.
The bigger picture: the update is a forcing function
You can only write "Done, Next, Blocked, Decisions" honestly if the trackers underneath are current. So the update quietly audits the whole setup every week.
A count you can't produce means a tracker nobody is keeping. A blocked item with no owner means a task that was never assigned. The update finds those gaps before a customer does.
It also changes the founder's role. They stop relaying messages between the 3PL, the developer and the factory, and spend their Friday on the handful of calls only they can make.
The ground rules from the setup plan still apply. Anything that spends money, changes priorities or affects many customers goes to the founders with options. The update is how those reach them on a schedule, not by accident.
Rollout checklist
- For two weeks, count founder status questions and note how long decisions take. That is your baseline.
- Agree the channel, the day and the time with the founders. Put it in their calendar too.
- Save a template with the five counts and the four headings: Done, Next, Blocked, Decisions needed.
- Make sure each count has a tracker behind it. If one can't be produced, fix that tracker first.
- Write each decision with the question, the options, the costs, a recommendation and a reply-by date.
- Link to tracker rows and tasks so the message stays short.
- Write it from the trackers on Friday morning and schedule it in Slack for the agreed time.
- Pin the latest update in the channel and unpin the previous one.
- Ask founders to answer decisions in the thread, and log each answer in the decisions channel.
- Turn the "Next" list into Monday's priorities post.
- After eight weeks, compare against the baseline and cut anything from the update that nobody reads.
It is one message a week. The discipline is in sending it every Friday, including the weeks when the news is not good.
Source: the Friday update and its targets come from my own operations setup plan. Tool and method details checked against Slack Help Center, Send or schedule a message, Slack Help Center, Pin messages and bookmark links, and Asana, How project status reports work, October 28, 2025. The system design and the expected effects are my own operator view.
Frequently asked questions
What goes in a Friday founder update?
Five counts at the top, then four headings in the same order every week: Done, Next, Blocked, and Decisions needed.
How should a decision be written?
So it can be answered in a line: the question, the options, what each costs, a recommendation, and the date an answer is needed by.
Can the update be automated?
The inputs can. Trackers fill through automations during the week, and Slack lets you schedule the message. The writing stays with a person. An AI first draft is allowed in the plan only with the founders' approval and a human check.
How do I know if it is working?
Baseline founder status questions and decision turnaround for two weeks, then compare after eight. Also watch decisions carried over, the age of blocked items, the five counts, and whether the update goes out on time.