Meeting Agenda Builder
Describe the goal and length, get a tight, time-boxed agenda and what people should prep.
What it produces
Real output from this tool, not a mock-up.
What went in
- What the meeting is for
- Weekly product and engineering sync. We keep overrunning and the last three have turned into status theatre where everyone reads out what they did. I want it to actually surface blockers and make decisions. Two things pending: whether we cut the reporting feature from the September release, and who owns the migration testing.
- Duration
- 30 minutes
- Who is attending
- Me (product), two engineers, the designer, and our QA lead. Five people.
Agenda
0:00-0:02 Framing: why this meeting exists now. Two decisions to close today, reporting feature scope and migration testing ownership. No status readouts, if something's on track it doesn't need airtime. Owner: Product 0:02-0:14 [Decide] Cut reporting feature from September release or not. Product lays out the tradeoff in 1 minute (what slips if it stays, what breaks if it goes), then engineers and designer weigh in on feasibility and cost of cutting it now versus later. QA flags any testing implications. Decision gets made in the room, not deferred. Owner: Product to drive, engineers and designer to weigh in 0:14-0:23 [Decide] Who owns migration testing. QA lead states current capacity and constraints, engineers state what they can take on. Land on a name before moving on. If it needs to split across people, define the split now, not as a follow-up. Owner: QA lead to frame, Product to close 0:23-0:27 [Discuss] Blockers only. Anyone stuck on something that needs another person in the room to unstick it, thirty seconds each, real blockers only, not a summary of the week. If nothing's blocking, this runs short and that's fine. Owner: whole group 0:27-0:30 Wrap-up: confirm the two decisions, confirm the migration testing owner by name, restate any blocker actions with names attached. Owner: Product Note: if reporting feature discussion runs long because the tradeoff is genuinely contested, protect the migration testing decision, it cannot slip another week. Push any deeper design or architecture discussion on reporting to a separate thread or a follow-up with just the people who need to be there.
What to do beforehand
- Product: come with a clear one-minute framing of the reporting feature tradeoff, don't build this live in the meeting
- Engineers: know your honest capacity for migration testing before the meeting, don't figure it out out loud
- QA lead: have current testing load and constraints ready to state in under a minute
- Designer: know whether cutting reporting affects any in-progress design work
- Everyone: identify in advance whether you have an actual blocker to raise, skip it if you don't
When to use it
Use this before a meeting that needs to produce something rather than just happen. Describe the goal and the length and you get a time-boxed agenda with an owner per item, plus what each person should do beforehand. It is most useful for the recurring meeting that has quietly turned into everyone reading out their status.