Project Kickoff Meeting Notes Template
The kickoff is the cheapest place to prevent expensive confusion
Most project failures are not execution failures. They are kickoff failures that took three months to surface: two teams with different definitions of "done," a scope boundary nobody drew, a dependency everyone assumed someone else owned. The kickoff meeting exists to settle exactly those things while settling them is still free — and the kickoff notes are the written proof of what was settled.
That makes the kickoff doc different from weekly notes. It is written once, referenced for the life of the project, and its most valuable sections are the ones other templates treat as secondary: scope — in and out, written as explicitly for what is excluded as for what is included, and open questions with owners and answer-by dates, because a kickoff that ends with unanswered questions and no names attached has simply scheduled its confusion for later. Copy the template, fill it in during the meeting (project it on screen — filling it live is what forces the vague answers to become specific), and treat the result as the project's founding document.
The project kickoff meeting notes template (copy and paste)
Blank template
# Project Kickoff — [Project name] **Date:** **Sponsor:** **Project lead:** **Attendees:** ## Why this project (background & problem) - ## Goals & success criteria - Goal: … | How we'll measure it: … ## Scope ### In scope - ### Out of scope - ## Milestones & timeline | Milestone | Owner | Date | |-----------|-------|------| | | | | ## Roles & owners | Area / deliverable | Owner | Consulted | |--------------------|-------|-----------| | | | | ## Dependencies - Depends on: … | Owner on the other side: … | Needed by: … ## Risks (initial pass) - Risk: … | Impact: … | Mitigation / owner: … ## Open questions - Question: … | Who will answer: … | Answer by: … ## Communication cadence - Status updates: [where, how often, from whom] - Working meetings: [what, when] - Escalation path: [who decides when the team is stuck] ## Decisions made at kickoff - Decision: … | Decided by: … ## Immediate next steps (first week) | Action | Owner | Due | |--------|-------|-----| | | | |
Example: the template filled in
A checkout redesign project at a mid-size e-commerce company. Notice especially the out-of-scope list — three items that each would otherwise have become a mid-project argument — and that every open question has a name and a date.
Filled example
# Project Kickoff — Checkout Redesign (Project Falcon) **Date:** Monday, Oct 20 **Sponsor:** VP Product (Ruth) **Project lead:** Daniel (PM) **Attendees:** Daniel (PM), Ana (Design Lead), Yusuf (Eng Lead), Marta (Data), Chris (Support Lead), Bea (Marketing) ## Why this project (background & problem) - Mobile checkout completion is 31% vs 58% on desktop. Exit surveys and session replays point at the payment step: form length, no wallet options, and an error state that clears entered data. - Support logged 340 checkout-related tickets last quarter. ## Goals & success criteria - Goal: Raise mobile checkout completion from 31% to 40% by end of Q1 | Measured by: checkout funnel analytics, 28-day post-launch window - Goal: Cut checkout-related support tickets by a third | Measured by: ticket tags, same window ## Scope ### In scope - Payment step redesign (form, wallet pay, error handling) - Cart review screen — layout only, no pricing logic changes - Instrumentation for the new funnel events ### Out of scope - Checkout for the B2B portal (separate project, Q3 earliest) - Pricing, discounts, or tax logic - Native app checkout — this project is mobile web only - Rebranding or visual identity changes beyond the checkout flow ## Milestones & timeline | Milestone | Owner | Date | |-----------|-------|------| | Research & current-state audit complete | Marta | Nov 7 | | Design concepts reviewed, direction chosen | Ana | Nov 21 | | Build complete on staging | Yusuf | Dec 19 | | Usability test (8 participants) + fixes | Ana | Jan 16 | | Launch to 10% of mobile traffic | Daniel | Jan 27 | | Full rollout decision | Daniel / Ruth | Feb 10 | ## Roles & owners | Area / deliverable | Owner | Consulted | |--------------------|-------|-----------| | Product decisions, scope calls | Daniel | Ruth | | Design | Ana | Chris (support insights) | | Engineering | Yusuf | Platform team | | Analytics & experiment readout | Marta | — | | Support readiness & help docs | Chris | Ana | | Launch comms | Bea | Daniel | ## Dependencies - Depends on: Payments platform team's tokenization API v2 | Owner on the other side: Wei (platform) | Needed by: Dec 1 for build start — confirmed at kickoff that v2 is in beta Nov 10 - Depends on: Legal review of wallet-pay terms | Owner: Daniel to book | Needed by: design review Nov 21 ## Risks (initial pass) - Risk: Tokenization API slips past Dec 1 | Impact: build start slips week-for-week | Mitigation / owner: Yusuf to build against the beta sandbox from Nov 10; weekly check-in with Wei - Risk: Holiday freeze (Dec 20–Jan 2) compresses usability testing | Impact: test starts late, launch date pressures quality | Mitigation / owner: Ana recruits participants in November, before the freeze ## Open questions - Question: Do we keep guest checkout or push account creation first? | Who will answer: Daniel with Marta's funnel data | Answer by: Nov 7 (feeds design direction) - Question: Is Apple Pay in for launch or phase 2? | Who will answer: Ruth | Answer by: Nov 14 ## Communication cadence - Status updates: one-page note in #project-falcon every Friday, from Daniel; milestones and risks only, no activity lists - Working meetings: design/eng sync Tue 30 min; full team check-in every second Monday, using the weekly team meeting template - Escalation path: Daniel first; scope or date disputes go to Ruth within 48 hours, not to the next steering meeting ## Decisions made at kickoff - Decision: Mobile web only for phase 1; native app is a separate business case | Decided by: Ruth - Decision: 10% staged rollout before full launch, kill-switch criteria defined by Marta before Jan 27 | Decided by: Daniel, agreed by all ## Immediate next steps (first week) | Action | Owner | Due | |--------|-------|-----| | Book legal review for wallet-pay terms | Daniel | Oct 24 | | Kick off current-state audit, pull funnel baseline | Marta | Oct 27 | | Set up staging against tokenization beta sandbox | Yusuf | Oct 31 |
Read the out-of-scope section again — "native app checkout," "pricing logic," "B2B portal" are all things someone would have requested by week three, each becoming a debate. Settled at kickoff, each becomes a one-line answer: "out of scope, per the kickoff doc." That is the return on 90 minutes of writing.
What a kickoff must settle (and what it can leave open)
Must settle before work starts:
- The problem and the measurable goal. If the room can't state how success will be measured, the project isn't ready to kick off — that's a finding, not a delay tactic.
- Scope boundaries, in and out, in writing.
- One accountable owner per deliverable. Committees don't own things.
- The first milestone and its date. A timeline that's vague at the start is fiction by the middle.
Fine to leave open — if each has an owner and an answer-by date:
- Design direction, technical approach, vendor choice. These are what the early milestones are for.
- Launch details (exact rollout percentages, comms copy). Deciding them at kickoff is premature precision.
The test: a new team member reading only this doc should be able to answer "what is this project, what is it not, who owns what, and what happens this week." If they can't, the kickoff didn't finish — schedule the second session now, not after the confusion arrives.
How an AI note taker helps with kickoffs
Kickoffs are long — 60 to 90 minutes, sometimes a half-day workshop — and dense with exactly the content that must not be paraphrased loosely: scope boundaries, commitments from other teams, dates. With CoHear, the session is recorded on an iPhone in the room (no bot, which matters when external partners or executives are present and a recording bot would change the room), and sessions can run 4+ hours, so a full kickoff workshop fits in one recording. You get the transcript and a structured summary back in about 65 seconds per hour of audio.
The practical workflow: record the whole kickoff, then build the kickoff doc from the transcript — pulling the scope statements and dependency commitments as verbatim quotes with timestamps, so when week six brings the inevitable "we never agreed to that," the record answers in the project's own words. The doc above stays human-owned and human-edited; the AI's job is making sure nothing said in the room is lost on the way into it.
From kickoff, the project cadence usually runs on the weekly team meeting notes template and closes each phase with a retrospective. For one-off meetings of other kinds, see the general meeting notes template.
FAQ
Who should attend a project kickoff?
Everyone who owns a deliverable, plus the sponsor who can settle scope disputes — and as few other people as possible. The test for each invitation: will this person make a decision, own a workstream, or be a dependency? Observers get the kickoff doc afterward; a 20-person kickoff produces alignment theater, not alignment.
What is the difference between a kickoff meeting and a planning meeting?
A kickoff aligns on what and why: problem, goals, scope, owners, risks. Planning works out how and when in detail: tasks, estimates, sequencing within a workstream. Kickoffs happen once per project with everyone; planning happens repeatedly within teams. Merging them produces a kickoff that drowns in task detail before the scope is even agreed.
How detailed should the kickoff document be?
Detailed on boundaries and ownership, light on method. Scope in/out, milestones, owners, dependencies, risks, and open questions should be specific enough to settle arguments later. How each team does its own work should not be in the doc at all. If the document runs past three pages, the excess is almost always solution detail that belongs in design or technical docs.
What do I do with the open questions a kickoff can't answer?
Never let them float. Each one gets a named owner and an answer-by date in the doc, and the project lead reviews the list weekly until it's empty. An unanswered kickoff question doesn't disappear — it resurfaces mid-project as a blocked team or a scope fight. The list is short at kickoff precisely because that's when answering is cheapest.
