A Weekly Growth Meeting Agenda

A weekly growth meeting keeps a team focused on metrics, experiments and learning. Without structure, it slowly turns into a round of status updates where everyone reports what they did, nobody challenges anything, and the meeting ends without a single decision. A clear weekly growth meeting agenda fixes that by giving each part of the hour a purpose: review what changed, understand why, look at experiments, capture what you learned and decide what to do next.

This guide explains how to set up that meeting for a small B2B SaaS team, who should attend, how to spend each block of time, what to prepare in advance, and the habits that keep it useful after the first few weeks.

What the meeting is for

The weekly growth meeting has one job: turning data and experiments into decisions. Everything on the agenda should serve that job. Reviewing key metrics tells you where you stand. Understanding what changed tells you whether something needs attention. Reviewing experiments tells you whether your bets are on track. Sharing learnings makes sure the whole team benefits from each result. Prioritizing next actions makes sure the following week has a plan.

It helps to say this out loud when you introduce the meeting. If people know the meeting exists to make decisions, they come prepared to make them. If they think it exists to keep the founder informed, they come prepared to report activity, and the meeting slides back into status updates.

Who should attend

A typical group includes the growth lead, someone from marketing, someone from product, a designer and an engineering representative. Sales or customer success should join when the agenda touches their work, such as an experiment on the trial-to-paid handoff or a change to onboarding that affects support volume.

Keep the group small enough for real discussion. Once a meeting grows past six or seven people, most attendees stop talking and the conversation narrows to two or three voices. At an early-stage company, the attendee list might simply be the whole team, which is fine as long as the agenda keeps it focused. As the company grows, resist the urge to invite everyone who is curious. Share the pre-read and the notes widely instead.

The engineering representative matters more than teams expect. Many experiments stall because nobody in the room can say how long a change will take or whether it is technically risky. Having an engineer present lets the group size work realistically and avoid committing to experiments that will sit in a queue for a month.

The agenda, block by block

A good weekly growth meeting fits in 45 to 60 minutes. Here is how to spend that time.

North star and key metrics (10 minutes)

Start with the north star metric, the one number that best reflects the value customers get from the product, then move through the main stages of the funnel: acquisition, activation, conversion and retention. For a product-led SaaS company, that might mean new signups, the share of signups who complete the key setup action, trial-to-paid conversions and the share of accounts still active after a set period.

The discipline here is to focus on changes and trends rather than reading every number aloud. Show this week, last week and a four-week average side by side. If a number is within its normal range, move on. Ten minutes disappears quickly if the group discusses every figure, and most weekly fluctuations are noise rather than signal.

Notable changes (5 minutes)

Use the next few minutes to discuss anything that moved beyond normal variation. If signups jumped, was it a newsletter mention, a seasonal effect or a tracking change? If activation dropped, did a release go out that touched onboarding? The meeting only needs to agree on whether the change is real and who will look into it. Often the right outcome is a single action item: one person investigates and reports back next week.

Experiment updates (15 minutes)

For each active experiment, cover its status, early observations, any issues and the expected completion date. This is the block most likely to overrun, so keep it tight. A useful rule is that experiments running smoothly get one line in the pre-read and no discussion time. Only experiments that are blocked, behaving strangely or need a decision get airtime.

When an experiment is blocked, the meeting should leave with a specific way to unblock it. That might be an engineer taking a ticket, a designer agreeing to deliver a variant by Thursday or the team deciding to drop the experiment because the blocker is too costly. An experiment that is blocked for three weeks running is a sign the team committed to more than it can deliver.

Completed experiment learnings (10 minutes)

For each finished experiment, review the hypothesis, the result, what the team learned and the decision. The decision is the part teams forget. Every completed experiment should end with one of three outcomes: ship the change, iterate with a new version or drop it. Writing the decision down closes the loop and stops old experiments from lingering in a half-finished state.

This is also the block where failed experiments earn their keep. An experiment that did not move the metric still tells you something about your users. Perhaps they don't care about the feature you highlighted, or the friction you removed was not the friction stopping them. Discuss what the result suggests about the next idea, not just whether it won.

Prioritization (10 minutes)

Review the experiment backlog and choose what to run next. Many teams use ICE scoring, which rates each idea on impact, confidence and ease, though any consistent framework works. A framework is useful because it forces the team to state its assumptions and compare ideas on the same terms.

To keep this block short, score ideas before the meeting. The person proposing an idea adds it to the backlog with a rough score and a one-sentence hypothesis. In the meeting, the group looks at the top few, argues about the scores where they disagree and confirms which ones go next.

Action items (5 minutes)

End by confirming every action's owner, deadline and dependencies. An action without an owner is a wish. An action without a deadline drifts. Dependencies matter because many growth experiments need help from someone outside the room, such as a developer on another team or a customer success manager who has to brief customers. Naming the dependency now prevents surprises next week.

Prepare in advance

The meeting only works if the preparation happens beforehand. Dashboards should be updated, experiment results added and the agenda shared at least a day before. When people walk in having already read the numbers, the meeting can spend its time on discussion instead of on someone screen-sharing a spreadsheet.

The simplest way to do this is a shared pre-read document with a fixed structure. It has a metrics section with this week, last week, the four-week average and a short note on anything unusual. It has an active experiments section where each experiment gets its hypothesis, status, early signal and any blocker. It has a completed section with each result, the learning and the decision. And it has a proposed-next section where each idea has an ICE score and an owner. Asking everyone to update their part of the document before the meeting is what makes the 45 minutes possible.

Keep a growth log

Alongside the weekly pre-read, keep a running log of every experiment, its result, the learning and the decision. Over months, this log becomes a knowledge base. When a new hire suggests testing a shorter signup form, you can show them that the team tried it, what happened and why. When the founder wonders whether pricing-page experiments are worth the effort, the log shows the history.

The log does not need special software. A single document or spreadsheet with consistent fields is enough. What matters is that it is updated every week as part of the meeting rather than retroactively when someone remembers.

Meeting rules that keep it useful

A few norms make the difference between a meeting people value and one they dread. Focus on decisions: if a discussion is not heading toward one, park it and move on. Avoid long status updates, since the pre-read already covers them. Encourage evidence-based discussion, where opinions are welcome but the group asks what data would change someone's mind. And celebrate learning, including failed experiments, because a team that only praises wins will quietly stop running risky tests.

The facilitator, usually the growth lead, plays an important role. Their job is to keep time, cut off tangents politely and make sure each block ends with a clear outcome. Rotating the facilitator role every few weeks can help others understand how hard it is to keep a meeting on track.

Add a monthly deep dive

Weekly meetings are good at spotting changes but poor at explaining long-term patterns. Once a month, replace part of the weekly meeting with deeper analysis. That might be a look at cohort retention, comparing how accounts that signed up in different months behave over time. It might be a review of channel performance, asking which acquisition sources produce customers who stay. It might be a full funnel analysis that traces where users drop off from first visit to paid account.

These deep dives often generate the best experiment ideas, because they reveal problems that weekly numbers hide. A retention curve that flattens later than expected, or a channel that brings lots of signups who never activate, points directly at the next set of bets.

Common mistakes

The most common failure is reviewing too many metrics. When the dashboard has thirty numbers, the meeting spends its time reading them and has none left for decisions. Pick a handful and keep the rest available for the monthly deep dive.

The second is ending without decisions. If the notes from a meeting contain observations but no actions, the meeting did not do its job. Third, experiments without owners stall, because everyone assumes someone else is handling them. Fourth, learnings that are discussed but not documented get forgotten, and the team repeats experiments it already ran. Finally, the meeting gradually becomes a status report, usually because preparation slips and people start presenting what should have been in the pre-read.

A worked example (illustrative)

A seed-stage SaaS team of six held a weekly growth sync that regularly ran 90 minutes and ended without decisions. Each person took a turn describing what they had worked on. Nobody challenged anything, and the next steps were vague.

They restructured the meeting to 45 minutes with a shared document prepared the day before. The first five minutes covered metrics from a single view showing signups, activation rate, trial conversions and monthly recurring revenue for this week, last week and the four-week average, and only changes beyond normal variation were discussed. The next fifteen minutes covered experiments, where each active test had one line in the pre-read and only blocked ones were discussed. Ten minutes went to completed experiments, each ending with a clear ship, iterate or drop decision. Another ten went to next bets, where the top three pre-scored ideas from the backlog were confirmed or swapped. The final five minutes assigned every action a name and a date.

The meeting became shorter, and the team ran more experiments each month because decisions were made in the room rather than deferred to the following week.

The takeaway

A weekly growth meeting earns its place on the calendar only when it produces decisions. Give each block of time a clear purpose, keep the metrics review short, spend discussion time on blocked and completed experiments, and leave with owners and deadlines for every action. Do the reporting in a pre-read, keep a growth log so learning accumulates, and step back once a month for a deeper look. Start next week with the agenda above and adjust the timings once you see where your team tends to overrun.