The structure of an excellent operating update
Great updates are hidden in plain sight. They make an observable bet and aren't shy to revisit that bet. Read: "Everything starts looking like a toy" #309
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: the LinkedIn Cringebot 3000. Put in your topic and identify your preferred style of post, and this site will happily give you a super-cringeworthy set of content. Yes, this will have your friends and contacts labeling you as “probably AI slop” but it’s fun to play with anyway.
Edition 309 of this newsletter is here - it’s August 17, 2026.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ The structure of an excellent operating update
If you asked five high performing people in your company what a great operating update looks like, you’ll almost always get a template. “Focus on the bottom line up front. Include next steps. Keep it to a minimum of information that people want to know.”
None of these instructions are wrong. However, they start with the assumption that the current job you’re working on matches the shape of that update. And that misses an important piece of context: how will that update hit in our organization. Also, when you find it later, will it make sense?
When organizations forget how to read past updates, they are doomed to repeat the same mistakes. The fix for that doesn’t automatically make it into a status update. You need to design it backward to deliver that outcome.
Building a better operating update
Let’s fix the purpose of the update first.
An operating update exists so that future you (or future teammate) can compare what was expected with what actually happened, and learn from the gap. That “diff” is where the learning is supposed to happen. If the only outcome is “we didn’t make it” then you didn’t learn enough to avoid that same output in the future.
Here’s a proposed definition:
an excellent update is one that preserves a complete learning event well enough for future readers to reconstruct it.
If this definition is true, then the effective product requirements for the better Operating Update are much clearer. They are an acheiveable outcome.
Here’s the question to answer: without this update, would future learning happen on this topic? A learnable update has to make a claim that could be wrong, and use it as a lever to see if we learned in the future whether the claim turned out.
An expectation without a testable claim (”we think this will lift activation by 4% in 30 days”, “we expect the migration to take 2 weeks”) ends up being activity tracking in a spreadsheet and doesn’t help us learn in the future.
There is an exception lurking here. When we provide activity-based updates on a project too many times in a row, it’s a valuable signal that a team is stuck. (One of the heuristics of creating good updates is to state non-goals or exceptions for those updates to know when they are out of whack.)
A new wrinkle to updates
Before I started writing this series, I answered the question “what makes a good update” with a definitional update. “A good update looks like this ...” and provided a few qualities of that update. But definitions are only one of the dimensions that move around when you are doing work.
I’m using cohorts more often in my descriptions of updates, because different customers are experiencing “day 7” or “day 1” or “day 28” problems. We need to consider their initial impression as one kind of operational problem, and the longitudinal impact of those impacts as a potential churn risk.
By tightening the update onto one particular type of customer instead of peanut butter-spreading that update across updates, you’re honing in on the real operational problem.
Is it good to improve things for all customers? Absolutely! Is it even better to identify a process break that happens for every customer at a specific point in time? Yep, better.
Don’t forget the honest assessment of what happened
The gap between our initial optimistic idea and the reality of what happened is the real update. It might feel embarrassing to note that the outcome was different than plan, but that’s the real signal.
When the outcome hits plan and the subsequent cohorts of customers behave the same way, we’re well calibrated. When we hit plan and encounter new problems that weren’t in the initial plan, we might be missing a use case or lacking telemetry to the real problems. Or when things seem fine but slowly degrade, that’s one of the more difficult problems to solve.
If we don’t talk about what’s actually happening, we’re not likely to learn anything. An update that hides surprises or an organization that isn’t equipped to alert on the unexpected will find these things out eventually.
What did we learn? Really ...
How do we prove that learning actually happened? An update that delivers learning has to say what you believe now that you didn’t believe before. Why does this matter? It’s going to help you guide what comes next.
“The migration took six weeks instead of three” could resolve to:
we need to write smaller migrations
we need more resources for migration
we need to rethink how we do migrations
Or any one of many outcomes that fan out from that learning experience. The point is that you should think of the task differently the next time you encounter it.
Writing your “surprise” or “learning” delivers a kind of runbook to the rest of the organization and drives a permanent change in how the team works. It’s the best way of solving the Bus Problem -- what we do if someone gets hit by a bus tomorrow and where is that knowledge -- that I know of.
An operating update emerges
We’re starting to get the shape of an excellent operating update:
what happened
to whom
by when
what did we learn
how did we change
But it’s not exactly a template. It’s a complete pass of the organization learning something from end to end using a vaguely scientific method. We use the update as the container for this experiment but we have to actually learn and apply the outcome if we want to call it excellent.
If the artifact of the learning misses one of these items, or the team doesn’t go through the work of testing the learning, then it’s pretty hard to reconstruct later. And that leads me to another key point.
We all have too much work in progress. Nope, AI doesn’t make this easier, and probably accelerates this trend.
When we have too much work going on at the same time, what’s going to be one of the first things to go? The space and time to consider the insights necessary to compose those items above that make a good update.
A compromise with these things in mind
That update needs to make sense to someone who wasn’t in your head. And that person (paradoxically) is going to be future you. In six months you will be on to another project, looking back at this one, and wondering “why did we make that decision? I can’t quite remember.”
So you need to be Theseus in the Labyrinth and use the updates as your metaphorical string to escape the scrambled memories to extract the impact of those decisions. “Expected outcome” is much more powerful when you understand the landscape where expected outcome happens.
Here’s the same team, in the same week, reporting the same news:
Activation — Week of March 14 Status: On track 🟢
Activation is up 4 points this quarter. The onboarding revamp shipped Tuesday, a day ahead of schedule, and early signals look strong. We also closed out the sample-data work and ran nine customer interviews to inform the next round.
Next up: templates in the invite flow. We’ll keep watching the funnel as the change rolls out to 100%.
Nice work by the team on a heavy sprint.
This isn’t bad, and tells you what’s going on. And it also doesn’t tell future you what the team was thinking when they wrote this. Nobody reading it in September can tell what the team believed in January, whether four points is ahead or behind, what “activation” counts, whether the revamp worked, or why templates are next. It records that the week happened.
Now the same week, built to be learned from:
Activation — Week of March 14
In January we bet that onboarding friction was what was holding activation back, and committed to +20 points by June — activation meaning a workspace with three or more active users in its first fourteen days. We’re at +4.
The revamp shipped Tuesday and did what it was supposed to: setup completion went from 61% to 78%. Activation barely moved. Nine interviews since suggest why — people finish setup and then have nothing worth inviting anyone to.
So we don’t think this is a friction problem anymore. We think it’s an empty-workspace problem, and if that’s right, templates should move activation more than anything left on the onboarding list. We’re moving templates ahead of the rest of that work, and we’ll know by mid-April.
This update puts a real success — setup completion up seventeen points — directly next to the fact that the thing it was supposed to cause didn’t happen. It names the new belief and it commits to a prediction that mid-April will confirm or kill. If the definition of activation drifts between now and June, you’ll be able to see it drift, because it’s written down here on March 14.
This is why updates aren’t simply about good writing. Excellent updates ≠ elegant and two sentences long. We want to capture the uncomfortable and learnable bits so they are very obvious to the team.
This observation doesn’t mean that an operating update needs to be a book. The point is that the update is built to be learned from instead of only read in a spreadsheet row and forgotten by next week.
None of this should seem new to you. I’m sure you can identify a great update when you see one. However, I’ll bet that you also are not building those updates systematically. My learning from writing about this process is that the update itself is a synthesizing and learning process and that I need to book time on my calendar to write it.
The anatomy of an excellent update was never really hidden. It’s been sitting inside a judgment that experienced operators make constantly and almost never write down.
What’s the takeaway? Writing the bottom line up front is a great way to start your update, and it doesn’t become excellent until you make a claim that’s probably true or false later. Evaluating the results of that claim gives the organization a surface to learn whether the bet was good.
Links for Reading and Sharing
These are links that caught my 👀
1/ Travel through foundation 990 reports - This is a pretty interesting data exploration through US charitable giving, courtesy of Mike Greenfield. Search for a private foundation you know, and see what you learn.
2/ How does Claude “watermarking” work? - If you’re wondering how Claude plans to track AI-generated work when text is copied from one app to another, you’re not alone. They are looking at the most likely word/token sequence, which makes me wonder: how much of my regular writing now sounds enough like Claude to trigger this?
3/ Nope, no time travel for me - Leave it to a physicist to explain why you don’t really want to time travel. I’ve got to hand it to Douglas Giles: he’s given me a new reason that I hadn’t considered before, and it’s compelling.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.