🚀 Great projects start with a written kickoff

PM Project Kickoff Doc
Template (2026)

The 10-section kickoff doc template, 6 kickoff mistakes to avoid, and when a kickoff doc is worth writing vs skipping.

Build PM Execution Skills Daily — Free →

10-Section Kickoff Doc

1. Problem statement (1 paragraph)

What problem are we solving, for whom, and why now?

2. Goals (1–2 primary)

What will be different when we're done? Outcome metrics, not feature lists.

3. Non-goals (explicit)

What we will NOT do in this project. Prevents scope creep before it starts.

4. Users affected

Which personas, what segments, what size (1K users? 1M?).

5. Assumptions

What we believe to be true. Riskiest assumptions flagged — they're the first things to test.

6. Approach (high level)

How we'll attack the problem. Not the PRD — just the shape of the work.

7. Timeline & milestones

Key dates — design review, code complete, QA, launch. Buffer for the unknowns.

8. Roles & RACI

Who's Responsible, Accountable, Consulted, Informed. Crisp names, not 'the team.'

9. Risks & mitigations

Top 3 things that could derail this, and what you'll do if they happen.

10. Success criteria

How we'll measure. Primary + guardrail metrics with targets.

When to Write One

Any project > 4 weeks of engineering time

Any cross-functional initiative (sales, marketing involved)

Any platform or infrastructure change affecting multiple teams

Any project with executive visibility

Any project where one person leaving would cause confusion

6 Kickoff Mistakes

Starting without a kickoff doc — 'everyone knows what we're doing' is never true

Too long — anything over 4 pages gets skimmed or ignored

No named owners — diffuse responsibility = nothing gets done

No timeline — ambiguity invites scope creep

No risks — signals over-confidence or incomplete thinking

Written in isolation — kickoff docs should be co-authored with eng/design leads

FAQ

How is a kickoff doc different from a PRD?

Kickoff doc = alignment artefact before work starts. PRD = detailed spec for what to build. The kickoff doc addresses: why this project, who's on it, what does done look like, what are the risks. The PRD addresses: exactly what to build. You need both — they serve different purposes and audiences.

Who should write the kickoff doc?

PM drafts, co-authored with engineering and design leads. The PM owns the problem statement, goals, and success criteria. Eng/design contribute to approach, timeline, and risks. Solo-authored kickoff docs miss blind spots and create false alignment.

When should the kickoff doc be reviewed and updated?

Reviewed once at project start with the full team. Updated whenever assumptions change significantly (scope change, timeline slip, new risks). Kill the habit of creating a kickoff doc then never looking at it — a living doc catches drift before it becomes crisis.

Build PM Execution Muscle Daily

Daily scenarios on scope, trade-offs, and alignment — the skills kickoffs require.

Start Free Trial →