You open a blank status-update document and remember a week full of work: calls, drafts, fixes, research, follow-ups. Yet none of it adds up to a clear answer to the question your manager, client, teammate, or instructor actually has: Where does this stand, and is anything needed from me?
The usual response is an activity list. “Attended planning meeting.” “Worked on draft.” “Reviewed data.” Those statements may be true, but they force the reader to infer progress and risk. A better update is built from evidence: the visible change in the work, the proof that supports your claim, the next checkpoint, and a specific request when one exists.
This approach is especially useful when a project is messy, shared, or still in progress. It does not make uncertain work look certain. It makes the uncertainty legible early enough for someone to help.
Why activity lists create more follow-up
Activity is an input. Progress is a change in the state of a deliverable.
For example, “I spent time on the presentation” leaves several important questions unanswered. Is there now a complete outline? Are the charts accurate? Is a decision blocking the final slides? Is the presentation ready for review? The reader has to ask, and you have to reconstruct the answer later.
Evidence-based updates reduce that reconstruction. They give each reader four pieces of information:
- Change: what is different since the last update.
- Evidence: the concrete artifact, check, decision, or result that supports the change.
- Next checkpoint: the next observable point at which the work can be reviewed or moved forward.
- Need: a decision, input, access, review, or acknowledgment required from someone else.
A status update is not a diary of effort. It is a small map that lets another person see the work, the uncertainty, and the next useful move.
Start with the thing that is supposed to exist
Before drafting an update, name the deliverable in plain language. This prevents busy work from becoming the center of the report.
A deliverable might be a recommendation, a draft policy, a cleaned dataset, a lesson plan, a hiring shortlist, a working feature, or an approved event plan. If the work has several outputs, choose the one most relevant to this update and mention the others only when they affect timing or scope.
Then ask one practical question: What could a reasonable person inspect today that they could not inspect at the previous update?
Your answer may be modest. A tested outline is a real change. So is a list of unresolved requirements, a set of comments incorporated into a draft, or confirmation that a source file contains missing fields. The goal is not to sound impressive; it is to locate the work accurately.
Use verbs that describe state, not effort
State verbs make updates clearer because they point to a condition that can be checked. Try drafted, reconciled, confirmed, selected, tested, consolidated, approved, identified, mapped, or flagged. Use them only when you can name what was drafted, reconciled, or tested.
Compare these two versions:
- Activity-based: “I worked on the onboarding guide and met with the support team.”
- Evidence-based: “The onboarding guide now has a complete first-pass sequence for account setup and common support questions; the support team confirmed the five issues that need screenshots.”
The second version includes the meeting only because it changed the work.
Keep a tiny evidence ledger while you work
You do not need to remember an entire week on update day. Keep a short running note, in whatever workspace you already use, with four labels: changed, checked, next, needed. Add a line when something material happens.
This is not a second task-management system. It is a filter for facts that will help you explain the project later. Keep it deliberately small. Notes such as “answered email” and “organized files” usually do not belong unless they removed a meaningful obstacle.
What counts as evidence
Evidence is not always a finished document. Depending on the work, it can be:
- a section of a draft that is complete enough for review;
- a decision recorded by the people responsible for making it;
- a comparison that eliminated an option;
- a check against agreed requirements;
- a prototype or sample completed for feedback;
- a discrepancy identified and isolated;
- feedback gathered and sorted into themes;
- a dependency that has been confirmed, delayed, or found to be missing.
Be precise about the strength of the evidence. “The form was tested with the available sample entries” is more honest than “The form works” if it has not been used more broadly. “The first draft is ready for content review” is more useful than “The draft is done” if editing and approval remain.
Write the update in four short parts
Once you have the facts, write in this order. The format works in a weekly email, a project channel, a meeting note, or a brief spoken update.
- Current state: Name the deliverable and its present condition.
- Evidence and significance: State what changed and why that matters.
- Next checkpoint: Name the next visible outcome, not merely more work time.
- Need or risk: Make one clear request, or state that no decision is needed now.
A compact version can be just four sentences. If the project has several workstreams, repeat the structure for each one rather than mixing updates into a long paragraph.
An illustrative update
Here is a hypothetical update for a team preparing a training session:
Current state: The training outline is ready for content review. Evidence: It now includes the required process steps, a practice exercise, and the questions collected from the support team; two policy points remain marked for confirmation. Next checkpoint: After those points are confirmed, the next version will include facilitator notes and timing. Need: Please confirm whether the exception process should be taught as a separate section or included in the final exercise.
Notice what the update does not do. It does not claim that the session is complete. It does not conceal the unresolved policy points. And it makes the requested decision narrow enough that a busy reader can answer it.
Make requests easy to answer
A vague problem report often produces vague reassurance: “Let me know if you need anything.” Instead, translate a blocker into the smallest decision or contribution that would release the work.
Weak request: “I am waiting on feedback.”
Stronger request: “Please choose either the short or detailed approval path by Thursday’s review, because the choice changes the instructions in sections 2 and 4.”
The stronger version names the choice, explains its consequence, and gives a meaningful point for response. If a date is imposed by a team process, use it; do not invent urgency just to make an update sound important.
Sometimes the correct update has no request. Say so plainly: “No decision is needed this week; the remaining work is formatting and internal checks.” This reassures readers that silence is intentional rather than an oversight.
Separate risk from inconvenience
Not every annoyance belongs in a status update. Include an issue when it can change scope, quality, timing, ownership, or the ability to make a sound decision. Leave out routine friction that you can handle without affecting those things.
When you do raise a risk, avoid predicting disaster. Describe the condition and its likely effect: “The source list does not include owners for three requirements, so those items cannot yet be verified.” Then state the next action: “I will send the three items for ownership confirmation.”
This phrasing is more useful than “There are major concerns,” because it gives the reader something concrete to assess.
Common ways this method goes wrong
Turning evidence into a document dump
Links, attachments, screenshots, and detailed notes may be valuable, but they are not an update by themselves. Summarize the point first. Offer the underlying material when the reader needs to inspect it.
Using false precision
A percentage complete can look authoritative while hiding disagreement about what “complete” includes. Use one only when the remaining work is defined and measured consistently. Otherwise, name the completed portion and the remaining checkpoint.
Hiding uncertainty until it becomes a deadline problem
An early “I need a choice between these two approaches” is usually more constructive than a late announcement that work cannot proceed. Raising uncertainty is not the same as escalating every minor question; it means surfacing the questions that alter the deliverable.
Adding too much history
Readers usually need what changed since the last update, not the entire origin story. Include background only when it explains a decision, constraint, or reversal that affects the next move.
Adapt the format without losing the point
Some teams require a fixed template, a tracker, or verbal round-robin updates. Keep the required format, but place evidence inside it. A “progress” field can name the changed state; a “blockers” field can hold the specific request; a spoken update can use the same sequence in fewer words.
For students, the reader may be a group partner rather than an instructor. “I completed research” becomes “I added three sources to the shared outline, noted which claims each one supports, and need the group to choose the example for the introduction.” The principle is the same: make your contribution and the next coordination point visible.
For work that is confidential or sensitive, describe the decision and project state without including restricted details in a broad channel. The method is about clarity, not oversharing.
Try it on your next update
Before sending your next progress note, write four rough lines: what changed, what shows it, what can be checked next, and what you need. Delete the activity list unless it explains one of those lines. Then read the update as someone who has not watched the work all week: could they tell what is true now and make the next needed decision?
That small edit turns an update from proof that you were busy into a tool that helps the work move.