TL;DR
A useful weekly product review does not summarize every meeting. It surfaces what changed and what now needs a decision.
Build one packet with six sections:
evidence changes → decisions → commitments → risks → unresolved questions → next checks
AI can draft the packet from authorized meeting records, but each material row needs a source and a review state. Do not let the model merge repeated opinions into demand, convert a design suggestion into approval, treat discussed work as committed, or close a risk because nobody mentioned it twice.
This workflow complements the broader product-manager meeting-notes system and the focused decision-log template. It owns the weekly review cadence rather than any single meeting type.
Why a summary of summaries fails
A product manager may finish the week with customer interviews, a design critique, Sprint Planning, a stakeholder review, an engineering sync, and a customer escalation. Asking AI to “summarize the week” creates three predictable errors.
Repetition becomes weight. The same concern mentioned in three meetings may come from one source repeated by three people. It is not three independent signals.
Different states collapse. A request, proposal, decision, selected task, and delivered change become one confident paragraph.
Quiet evidence disappears. A technical constraint or contradictory interview may receive less airtime than a popular opinion, even when it should change the plan.
The weekly packet should therefore be a delta review, not a digest. Record only material changes, decisions, accepted commitments, active risks, unresolved questions, and the next evidence that could alter them.
GOV.UK's research-planning guidance asks teams to agree research questions, involve the team in analysis, and feed findings into planning and prioritization. Its roadmap guidance describes roadmap development as iterative, collaborative work informed by user research and performance analysis. A weekly product packet is one practical review surface for that work; it is not a GOV.UK-prescribed template.
Define the source boundary first
List the records the packet may use:
- reviewed meeting transcripts or notes;
- approved research findings;
- current decision records;
- tracker state from the system of record;
- authorized metrics or experiment results;
- technical, privacy, accessibility, legal, or support constraints supplied by their owners.
Do not ask the model to discover authority or truth by searching everything it can access. A bounded packet is easier to inspect and less likely to leak unrelated information.
The six-section weekly packet
1. Evidence changes
Record only evidence that is new, corrected, contradicted, or materially stronger or weaker than last week.
| Field | Record |
|---|---|
| Change | New, corrected, contradicted, stronger, weaker |
| Source | Recoverable meeting, artifact, metric, or research reference |
| Observation | What the source directly supports |
| Previous belief | The prior finding or assumption affected |
| Coverage | Users, workflow, environment, dates, and gaps |
| Required review | Research, product, data, engineering, or another owner |
Do not count repeated paraphrases as additional evidence. Preserve source lineage.
2. Decisions
List decisions made, deferred, revisited, or superseded this week. Link the full record when one exists.
| Decision | State | Authority | Scope | Evidence | Review trigger |
|---|
If the meeting only produced a recommendation, leave the state proposed.
3. Commitments
Include only work explicitly accepted by an owner or team.
| Action | Owner | Due or review date | Destination | Dependency | Status source |
|---|
Do not claim completion from a meeting statement alone. Check the tracker or artifact when policy permits.
4. Risks and constraints
Keep each risk tied to evidence and an owner.
| Risk or constraint | Evidence | Impact if true | Owner | Mitigation state | Next check |
|---|
Separate observed defects from possible risks. Separate a policy constraint from a person's interpretation of that policy. Do not invent severity or probability scores.
For a service outage or security incident, use an evidence-first incident review packet instead of treating the review as an ordinary weekly risk. Incident timelines, impact, causal analysis, and corrective actions need their own source and approval boundaries.
5. Unresolved questions
Write the question, why it matters now, what would answer it, and who can provide that evidence. Promote a question when it blocks a decision or commitment; do not hide it at the end of the packet.
6. Next checks
The packet ends with the events that may change the plan next week:
- a research session or synthesis review;
- a technical spike or validation result;
- a metric cutoff or experiment read;
- a design revision and verification;
- a policy or security review;
- a customer update;
- a decision trigger reaching its date.
Worked example: onboarding reliability week
During one week:
- two interviews reveal uncertainty about workspace completion;
- a design review proposes a clearer completion state but does not approve it;
- engineering confirms that migrated workspaces lack a reliable completion event;
- Sprint Planning selects instrumentation for new workspaces and defers the UI change;
- Support requests a known-issues note before any external rollout.
| Section | Reviewed entry |
|---|---|
| Evidence change | New observation from two interviews; limited coverage; supports further investigation, not prevalence |
| Decision | UI change deferred until completion state is technically reliable |
| Commitment | Instrumentation task accepted for new workspaces; owner and tracker link confirmed |
| Risk | Migrated workspaces may report an ambiguous state; external rollout remains out of scope |
| Question | What event proves completion across migrated paths? |
| Next check | Review instrumentation result and Support's rollback/known-issues requirements |
The packet does not say the feature is prioritized, scheduled, or customer-ready. It carries forward the precise state.
Copyable prompt for a draft weekly review
Use this only with approved sources:
Prepare a DRAFT weekly product review packet from the supplied source set. Compare against the prior reviewed packet when provided. Return only material changes in six sections: evidence changes, decisions, commitments, risks and constraints, unresolved questions, and next checks. For every row, include a recoverable source reference, scope, review state, and required owner. Do not count repeated paraphrases as independent evidence. Do not infer user frequency, priority, authority, approval, assignment, due date, severity, probability, completion, or roadmap commitment. Preserve contradictions. Mark missing or conflicting fields NEEDS REVIEW. Label the full output DRAFT FOR WEEKLY PRODUCT REVIEW.
Review the packet in this order:
1. Research or source owners verify evidence and coverage. 2. Decision owners verify state, rationale, and scope. 3. Action owners verify commitments and tracker destinations. 4. Risk owners verify wording and next checks. 5. The product owner or product manager publishes the reviewed packet according to team policy.
Where Shadow fits
Shadow's current Help documentation describes local meeting capture, transcription, speaker diarization, meeting Markdown, and available media in the local vault. The meeting review lets an authorized user inspect transcript timestamps, audio, notes, screenshots, Skills, and Ask.
A configured Meeting Skill can draft a structured result after processing, and supported Skills can save Markdown or send output to a configured webhook. Generated claims, decisions, owners, and dates still require review. Shadow's current Help documentation does not describe automatic week-wide meeting comparison, tracker reconciliation, experiment verification, or publication of an approved product review packet.
When Smart Screenshots are enabled, captures can preserve changing visual context locally while Listening is active and a target is available. A screenshot does not by itself establish which product version, metric, or decision is authoritative.
Review privacy and data leaving your Mac before using external AI, Ask, sharing, or webhooks. Obtain the required recording consent before capture. Keep sensitive sources and destinations inside the boundary your organization has approved.
What is real, what is interpretation, and what is unproven
Real now
- Product roadmaps and research plans are iterative and informed by reviewed evidence.
- Different product meetings produce different artifact and authority states.
- Shadow currently supports local meeting records plus optional reviewable Skill output under documented boundaries.
Interpretation
- The six-section delta packet is this article's proposed weekly review method.
- Comparing with a prior reviewed packet can make material changes easier to isolate.
- A fixed review order can help teams locate which owner must correct each field.
Unproven
- This article does not claim the packet improves prioritization, velocity, alignment, or product outcomes.
- It does not claim repeated meeting mentions measure customer demand.
- It does not claim Shadow automatically assembles, verifies, reconciles, or publishes the packet.
Measure the packet for four weeks
| Check | Question |
|---|---|
| Materiality | Did the packet include only changes that could affect a decision or action? |
| Source recovery | Can each row be traced without searching every meeting? |
| State precision | Were proposals, decisions, commitments, and risks kept separate? |
| Correction rate | Which fields changed during owner review? |
| Carry-forward | Did unresolved questions and triggers survive into the next packet? |
| Route safety | Did only reviewed commitments reach external systems? |
Do not report time saved until you have measured the actual review and correction work. A shorter packet with explicit uncertainty is more useful than an automated executive summary that needs to be reverse-engineered.
If this cadence fits your product team, download Shadow and test one draft weekly packet from authorized meetings. Keep it in draft until the evidence, decision, action, and risk owners have reviewed their sections.
Sources and verification date
This article was researched and verified on October 5, 2026.