Discovery and Kickoff: The Document That Starts a Project Right

The single moment that determines whether a project ships or drifts is the kickoff. Done well, the team enters week one with shared context and committed scope. Done poorly, every week of the project pays the cost of unclear ownership. This chapter shows the discovery questions, the kickoff doc, and the 90-minute meeting that turns one into the other.

When does a formal kickoff actually pay back?

Three signals.

Project longer than 4 weeks. Below that, a Slack thread captures the start; above that, you need a doc that survives the first surprise.

Team did not start it together. When some engineers were involved in pre-sales / discovery and others join at start, only a kickoff doc transfers the missing context.

Multi-stakeholder commitment. When sales, legal, marketing, or external customers will judge the result, you need a written record of what was agreed. Memory disagrees; documents do not.

If you are 2 engineers building an internal tool you will use yourselves, skip the kickoff and ship.

What is the cost of skipping kickoff?

Three failure modes.

Wrong-thing-built syndrome. The team thought it was building A; the sponsor thought B. Six weeks in, demo reveals the gap. Three weeks redoing.

Surprise stakeholders. Legal arrives at week 6 with a must-have requirement. Two weeks of unplanned work added.

Scope drift from week one. Without a written scope, every "could we also..." gets folded in silently. By month two the project is twice the original size.

What does the minimal kickoff doc look like?

For a 6-week project with a 5-person team:

# Kickoff: {{ Project Name }}

## Why now
We are doing this project because {{ market signal, customer pain,
or strategic decision }}. Specifically, {{ measurable outcome we
expect: increase X by Y%, reduce churn by Z%, ship before
competitor }}.

## Success looks like
By {{ date }}, {{ specific user-visible state }}, measured by
{{ metric and target }}.

## In scope
- {{ Capability 1 — specific, demonstrable }}
- {{ Capability 2 }}
- {{ Capability 3 }}

## Out of scope (deferred)
- {{ Thing we explicitly will not do this round, with reason }}
- {{ Future-phase item }}

## Roles (RACI for big decisions)
| Role | Person | RACI for scope changes |
|------|--------|------------------------|
| Sponsor | {{ name }} | A |
| Tech Lead / PM | {{ name }} | R |
| Engineers | {{ names }} | R |
| Design | {{ name }} | C |
| Legal review | {{ name }} | C (one-time at week 4) |

## Top 3 risks
1. {{ Risk + mitigation + owner }}
2. {{ Risk + mitigation + owner }}
3. {{ Risk + mitigation + owner }}

## Decision deadline
{{ Date by which we commit or kill }}. Until that date, this
document is provisional.

## Trial period
This kickoff doc is treated as draft for one week. Comments,
disagreements, and scope clarifications welcome through {{ date }}.
After {{ date }}, scope changes follow the change-request process
in the [stakeholder chapter](/tech-pm/stakeholders-and-comms).

The trial period clause is the secret weapon. It gives the team a week to push back without making them feel like they are challenging the sponsor publicly. Most useful clarifications come in this window.

What is the 90-minute kickoff meeting agenda?

# Kickoff Meeting Agenda — 90 minutes

00:00 - 00:10  Sponsor: why this project exists (10 min)
00:10 - 00:25  Walkthrough of in-scope and success criteria (15 min)
00:25 - 00:40  Walkthrough of out-of-scope and the reason (15 min)
00:40 - 01:00  Round-table: each engineer flags concerns (20 min)
01:00 - 01:15  Top 3 risks: agree owners and first mitigations (15 min)
01:15 - 01:25  Decision deadline + trial period explained (10 min)
01:25 - 01:30  Confirm next meeting + how status will be reported (5 min)

The most-skipped part is the round-table. Engineers who saw the doc but did not get to voice concerns publicly will surface them later as resistance. Two minutes per person up front prevents this.

How does kickoff scale to multi-team?

flowchart TB
    Discovery[Discovery 1-2 weeks] --> ProgKickoff[Program kickoff<br/>90 min, all teams]
    ProgKickoff --> TeamA[Team A kickoff<br/>90 min]
    ProgKickoff --> TeamB[Team B kickoff<br/>90 min]
    ProgKickoff --> TeamC[Team C kickoff<br/>90 min]
    TeamA --> Plan[Per-team planning]
    TeamB --> Plan
    TeamC --> Plan

A program kickoff sets the high-level why-now and decomposes scope across teams. Each team then runs its own kickoff to commit to the slice it owns. The program kickoff doc lives at the program level; team kickoff docs live in each team's repo. Both reference each other.

What failure modes does kickoff introduce?

• Kickoff theatre. A long doc nobody reads, presented for an hour, archived. Mitigation: < 1 page; everyone reads silently for 5 min at the meeting start; the meeting is for discussion, not reading.
• Sponsor speech-only. Sponsor talks for 60 of the 90 minutes. Mitigation: cap sponsor at 10 min; the rest is team discussion.
• No decision deadline. Document feels open-ended; team cannot commit. Mitigation: every kickoff has a deadline by which the doc moves from draft to committed.
• Skipping out-of-scope. Only listing in-scope means "everything else might be in-scope". Always write out-of-scope explicitly.

When is kickoff overkill?

Two cases.

Hot fix or incident response. When something is on fire (see incident chapter), running kickoff theatre is the wrong response. Triage, fix, post-mortem.

Continuous-flow work. A platform team accepting steady ticket flow does not need a per-ticket kickoff. The team's charter and the Kanban board are the permanent kickoff equivalent.

The kickoff earns its 90 minutes when the project has a defined scope, a team, and a deadline. Below that, lighter artifacts work.

Where should you go from here?

Next chapter: planning and roadmap - turning the kickoff doc into a phased plan the team can execute. After that, sprint execution covers the weekly cadence inside that plan.