A weekly review that ends with a decision

A weekly review earns its place when it helps a team decide what to do next. It can be tempting to use the meeting to read through everything that happened, especially when work is spread across people and tools. A more useful approach is to prepare the updates beforehand and spend the shared time on questions that need a decision, help or a change of plan. The result is a routine that people can prepare for and repeat.

The example in this guide is a small team testing a new customer-onboarding workflow. One person handles interviews, another changes the product and a founder coordinates the pilot. The team needs to understand what has happened, choose the next test and resolve obstacles. The agenda is designed to be copied into the team’s next review and adjusted after use.

Give the meeting a defined purpose

Write one sentence describing what the review is meant to produce. For this team, it could be: decide the next onboarding test and resolve anything that prevents the current pilot from running. That sentence helps determine who needs to attend and what information must be prepared. It also gives the facilitator a way to bring a drifting discussion back to the work.

Separate a decision meeting from a general update. Some updates can be read in advance. Some topics need a specialist conversation with only two people. A recurring team meeting should have a reason for bringing everyone together. If the week contains no shared decisions or obstacles, the team can choose a shorter check-in or an asynchronous review with a clearly stated route for questions.

Ask for concise preparation

Before the review, each owner can record what changed, the evidence behind it and the decision or help they need. Link the relevant material so colleagues can inspect it without reconstructing a history from chat. A prepared update might say that two pilot participants could not find the invitation step, identify the observed sessions and ask whether the team should test a revised label.

The evidence should be described accurately. A customer comment, a support request and a measured product event are different observations. The Nielsen Norman Group framework for research methods offers a useful distinction between what people report and what they do. In a review, that distinction helps the team choose a follow-up question rather than treat every note as the same kind of proof.

Open with the decisions already made

Start by checking the actions agreed at the previous review. For each one, ask what happened and whether the result changes the current plan. An incomplete action needs an explanation of the constraint and an updated owner or next step. The purpose is to understand the state of the work so today's decisions begin from a shared picture.

In the onboarding example, a previous action might have been to arrange three observed setup sessions. If only one happened, the team should understand why. Perhaps recruiting was harder than expected or the intended users were unavailable. That information affects the next plan. Repeating the original target without examining the obstacle leaves the team with the same problem for another week.

Choose a small set of questions

Collect the decisions that require the group and choose the most useful ones for the time available. Phrase each as a question with a clear object. “Which invitation wording will be tested next?” is easier to resolve than “Discuss onboarding.” Include the options, relevant evidence and the person responsible for making or confirming the decision. That preparation makes participation more concrete.

The team may disagree about whether it has enough evidence. Give that disagreement a place in the record. One option might be to run a smaller test before committing engineering time. Another might be to make a reversible change and observe it closely. The decision should reflect the cost and reversibility of the next step, with a named person responsible for gathering what is missing.

Keep observations and explanations visible

During the discussion, separate what happened from why the team thinks it happened. A user may have abandoned setup after seeing an unfamiliar label. The explanation could involve the wording, the person's permissions or a missing piece of context. Writing those possibilities down helps the team choose a test that can distinguish between them. The meeting becomes a place to improve the next question.

The GOV.UK guidance on user needs encourages continuing research throughout development. For a weekly review, that means retaining a route back to users as the product changes. A team can keep a short list of unresolved needs and identify which one the next observation should address. The review then connects delivery work with the people the product is meant to serve.

End each discussion with a usable action

An action needs an owner, a specific output and a point when it will be checked. “Improve the onboarding flow” leaves the next person to interpret the task. “Prepare two invitation-label variants for a walkthrough before the next review” gives the owner a concrete piece of work. If a dependency exists, record who will resolve it and how the owner should proceed if it remains blocked.

A decision record can stay short: question, selected option, reason, owner and next check. Link supporting material rather than copying it all into the note. The person who misses the meeting should be able to understand the result. A future team member should be able to see why a choice was made and which assumptions were still open when the work began.

Leave room for an honest stop decision

A review should also make it possible to stop or postpone work. If a test no longer answers an important question, the team can close it and preserve what was learned. If a project depends on access that is unavailable, it can be moved out of the active list until that condition changes. Keeping everything marked as active makes it harder to understand where effort is actually going.

In the example, the team might postpone a larger dashboard change while it investigates a confusing invitation step. That is a specific allocation of attention. The record should show what will be revisited and what would trigger the revisit. A short, visible decision gives people permission to focus on the selected work during the following week.

Improve the routine through use

After a few reviews, ask whether preparation is useful, whether decisions are clear and whether actions return with enough evidence. Adjust the template where it causes extra work or hides relevant information. A team may need a shorter update field, a clearer decision question or a separate place for research material. The review format should develop around how the team actually works.

A founder building a workspace or advisory offer under GrowBy could begin with this weekly routine as a concrete customer job. The name can carry a focused first offer while the method becomes more capable through use. For any small team, the immediate step is simple: write the next review's decision questions before adding updates to the agenda, then prepare the evidence needed to answer them.