How to Draft a Weekly Linear Product Update in Slack

To draft a weekly Linear product update in Slack, give Mio a defined issue scope and date window, group the returned activity by project and keep a source link beside each item. Call an issue completed this week only when its completion date is supported. Call it released only when separate release evidence confirms availability.

Start with the question your team needs answered

A founder asks what moved. Engineering wants blockers and next decisions. Customer-facing teammates need to know what is available. Those are related questions, but they should not all receive the same list of tickets marked Done.

Mio is a Slack-native AI employee that can read connected Linear issues, group an update by project and deliver it in Slack. Start with an internal issue summary. It gives the team a compact view without turning every workflow status into a customer promise.

Define the window and the issue scope

Specify the team or projects, the start and end of the reporting interval, and the time zone. State whether you want activity during the window, current status, or verified completions. Use an inclusive start and exclusive end so adjacent weekly reports do not count the boundary twice.

For example, a Monday report could cover the previous Monday at 09:00 up to the current Monday at 09:00 in Europe/Paris. That is a reporting convention, not a claim that every issue updated during that interval was finished then.

Linear's filter documentation explains how to narrow views by properties such as status, project and cycle. Use a focused view to check the report against its source. Filters define the population; they do not supply missing evidence about completion or release.

Keep three kinds of evidence separate

Consider a fictional issue completed last month and edited this Thursday. Its status is still Done and its latest update is recent. It belongs in a recent-activity report, but counting it as a completion this week would be wrong. If the connected data lacks a completion timestamp or useful history, say 'currently Done; updated during the window' and leave the completion date unverified.

Do not calculate a weekly completion total from that weaker group. Do not rename the section 'Shipped' to make it easier to scan. For a customer announcement, use the separate release-note review workflow, which starts with verified availability.

A copy-paste request for the first draft

Replace the bracketed scope and dates. This template sets the review rules; it does not assume every connected workspace exposes the same history fields.

@mio draft an internal Linear update for [teams/projects], covering [start inclusive] to [end exclusive] in [time zone]. Group issues by project and link each issue. Separate: verified completions during the window; other issues updated during the window with their current status; explicit blockers or decisions recorded in the source. For each claimed completion, include its completion-date evidence. If that evidence is unavailable, label it currently Done, completion date unverified; do not count it as completed this week. Do not infer release or customer availability from Done. Show query scope, coverage limits and unresolved questions. Return the draft only in this DM. Do not edit issues or post to another destination.

The useful output is a short project summary with inspectable evidence, not a rewritten issue description for every row. Keep an item-level appendix or links when the reader needs to check a claim. Mark an issue without a project as unassigned rather than silently dropping it.

Review the edge cases before scheduling

• Check an old completed issue edited this week. It must not inflate the completion count.
• Check a new completion against its recorded completion date, not only its current status.
• Check the exact interval boundary and time zone against the source.
• Check an issue that appears through more than one project or query path. Count the issue once.
• Check a reopened issue. Preserve its current state and explain the transition if supported.
• Check a claimed blocker. A quiet issue is not automatically blocked; missing evidence should remain a question.

Keep these examples as workflow acceptance tests. A source-linked message is easier to audit, but a link alone does not make its summary correct. If a query is partial or a tool fails, the draft should disclose the missing coverage instead of presenting an exhaustive count.

Make the reviewed version recurring

Once the first draft matches the source, ask Mio to repeat the same job at a stated time and send it to the same private destination. Confirm the saved scope, schedule, time zone and recipient. Treat a move from DM to channel as a separate delivery decision, not an implied consequence of scheduling.

The recurring-workflow runbook can hold those settings and the person responsible for exceptions. Scheduling does not remove editorial review: source conventions can change, issues can be reopened, and incomplete reads can make a familiar report misleading.

Try a Linear update with Mio in Slack. Start with one project and one reporting window. Keep the job if it produces a useful, checkable draft, not merely because it sends a message every Monday.