How to Create a Weekly Product Update in Notion
Weekly product updates are the connective tissue between your team's work and the rest of the organization. When done well, they eliminate status meetings, reduce 'what is the status of X' Slack messages by 80%, and create an invaluable historical record of decisions and progress. When done poorly, they become a chore that nobody reads.
The key to a weekly update that people actually read is structure and brevity. Notion's database and template features let you create a system where each update follows the same format, is easy to write in under 15 minutes, and gives readers the ability to quickly scan for what matters to them. This guide walks through building that system from scratch.
Step-by-step guide
Create the updates database
In your team's Notion workspace, create a full-page database called 'Product Updates.' Add properties for Date (date type, set to the Friday of each week), Author (person type), Status (select with options: Draft, Published), and Tags (multi-select with options like Launches, Metrics, Decisions, Blockers). Set the default view to a list sorted by date descending so the latest update is always at the top.
- Create a new database page called 'Product Updates'
- Add Date, Author, Status, and Tags properties
- Set default view as a list sorted by date descending
Design the update template
Click the dropdown arrow next to 'New' in your database and select 'New Template.' Build the template with five sections: a 'TL;DR' callout block at the top with 3 bullet points maximum, a 'Shipped This Week' section with a table (Feature, Status, Impact), a 'In Progress' section with progress indicators, a 'Key Decisions Made' section, and a 'Next Week Focus' section. Each section should have placeholder text that guides the author on what to include.
Set up the TL;DR section for scanners
The TL;DR is the most important section because most readers will only read this. Use a Notion callout block with a distinctive icon. Write exactly 3 bullet points: one about the biggest thing shipped, one about the most important metric or decision, and one about the biggest risk or blocker. If a reader only spends 10 seconds on your update, these three bullets should give them everything they need.
Build the shipped and in-progress tables
For 'Shipped This Week,' use an inline table with columns for Feature Name (linked to the project page), Ship Date, and User Impact (one sentence). For 'In Progress,' add columns for Feature Name, Progress (percentage or status), Target Date, and Risk Level (green/yellow/red emoji). Keep both tables concise. If something did not ship and is not at risk, it does not need to be in the update.
- Create an inline table for shipped items with feature, date, and impact
- Create an inline table for in-progress items with progress and risk
- Add instruction text explaining when an item warrants inclusion
Add the decisions and blockers sections
The 'Key Decisions Made' section should capture 1-3 decisions per week in a consistent format: 'We decided [decision] because [reasoning]. Alternative considered: [what you didn't do].' This creates an invaluable decision log. The 'Blockers' section lists anything that is preventing progress, who owns unblocking it, and when it is expected to be resolved.
Create distribution automations
Set up an automated workflow so your update reaches people where they already are. Use Notion's Slack integration to post the update to your team channel when the Status property changes to 'Published.' Add a recurring calendar event on Friday at 3pm titled 'Write Product Update' with a link to the database. Some teams also email a summary to leadership using Notion's email integration or a Zapier workflow.
- Connect Notion to Slack for automatic posting on publish
- Create a recurring calendar reminder for the author
- Set up email distribution for stakeholders not on Slack
Establish the feedback and archive system
Add a 'Comments' toggle at the bottom of the template where stakeholders can ask questions or flag concerns. Review comments on Monday and address them before the next update. Create a Notion gallery view of the database grouped by month for easy browsing of historical updates. After a quarter, archive updates older than 3 months into a linked database view so the main view stays clean.
Common mistakes
Writing too much
A weekly update that takes 20 minutes to read will not be read. Target 2-3 minutes of reading time. Cut ruthlessly. If stakeholders need more detail on a specific item, they can click through to the project page. The update is a summary, not a report.
Including only good news
Updates that only report wins lose credibility. Include blockers, delays, and decisions to cut scope. Honest updates build trust and surface problems early enough to address them. A PM who only reports green lights is either not being honest or not tracking closely enough.
Not linking to source materials
Statements like 'activation improved this week' without a link to the data are unverifiable. Every claim should link to the dashboard, PRD, or design file that supports it. This makes the update a hub that connects readers to deeper context.
Tips
Write your TL;DR last, after the rest of the update is done. It is easier to summarize when you can see everything that happened.
Keep a running draft throughout the week. Add bullet points to next week's update on Monday through Thursday so Friday's writing session is assembly, not recall.
Use Notion's @-mention feature to tag people who are directly responsible for blocked items, so they see the mention in their notifications.
Review your last month of updates quarterly. If the same items appear as 'In Progress' for more than 3 weeks, escalate or re-scope them.
How Vantage helps
Vantage gives PMs the context they need to write accurate weekly updates quickly. By tracking project progress, ticket status, and requirement completion in one workspace, you can pull the data for your Notion update directly from Vantage rather than assembling it from three different tools every Friday.