Verified against ChatGPT · 2026-08-10
Write a project kickoff brief that answers the three questions every kickoff meeting re-litigates
Produces a kickoff brief pre-answering scope, ownership, and done-ness before the meeting starts, so the actual kickoff conversation moves past the questions that usually eat the whole hour.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Write a project kickoff brief for the project below, built specifically to answer the three questions every kickoff meeting ends up re-litigating live: who owns what, what does done actually look like, and what happens when something in scope turns out to be harder than expected.
PROJECT NAME AND GOAL
Self-serve refund flow — let customers request and receive standard refunds without a support ticket.
SPONSOR AND DECISION MAKER
Sponsored by the Head of Support; final scope/deadline calls rest with the Product Lead, Marcus.
TEAM MEMBERS AND ROLES
Priya (backend engineer), Sam (frontend engineer), Dana (support ops, part-time on this project), Marcus (product lead).
HARD DEADLINE OR CONSTRAINT
Must launch before the holiday return-season spike, six weeks from now.
DEFINITION OF DONE
Given as 'refunds should be self-service' — no specifics on which refund types or what edge cases are covered.
Open with the goal in one sentence, stated as an outcome, not an activity — 'ship a working self-serve refund flow' rather than 'work on refunds.' Then build an ownership table from the team members and roles given: for each person, state not their job title but the specific decision types they own for this project, since kickoff meetings burn time re-deciding ownership that was never actually assigned to a name. Write the definition of done as a specific, checkable condition — something the team could point to and agree it's either met or not met — and if what was given is vague ('the feature works well'), rewrite it as the sharpest checkable version you can construct and flag that it needs the sponsor's confirmation. State the hard deadline plainly along with what it actually constrains — if the deadline conflicts with the definition of done given the team size, say so directly rather than presenting both as simultaneously achievable when they may not be. Add a short section anticipating what happens if a scoped-in piece of work turns out to be significantly harder than expected mid-project — name who has authority to cut scope versus who has authority to push the deadline, since without this stated upfront, that exact moment turns into an unplanned escalation later.
WHAT NOT TO DO
Do not write generic kickoff boilerplate ('let's align on goals and next steps') — every line should reference this specific project. Do not leave ownership assigned to a team or department rather than a named individual; a shared owner is not an owner.
OUTPUT FORMAT
1. Goal, one sentence, outcome-framed.
2. Ownership table: name, specific decisions they own.
3. Definition of done, checkable, with a flag if it was sharpened from something vaguer.
4. Deadline/constraint, with an explicit note if it conflicts with the definition of done.
5. Scope-pressure plan: who cuts scope vs. who moves the deadline if something proves harder than expected.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Kickoff meetings that feel like they accomplished nothing usually spent the hour re-litigating exactly three things live — who's actually responsible for what, what counts as finished, and what happens if scope turns out to be bigger than expected — because none of them were pinned down beforehand in writing, so building the brief specifically around pre-answering those three collapses the part of the meeting that otherwise eats all the time into a document people can react to instead of construct from scratch in the room. The instruction to assign ownership to a named individual for specific decision types, not a role or a shared team, targets a very common and costly ambiguity: 'the engineering team owns backend decisions' sounds like an assignment but functions as no assignment at all the moment a real decision needs to be made under time pressure, because no single person feels the accountability is theirs specifically. Sharpening a vague definition of done into a checkable condition — and explicitly flagging that it needs sponsor confirmation rather than silently presenting the sharpened version as agreed — matters because GPT-5.1 will otherwise happily generate a confident-sounding 'done' criterion that reads as settled, when in fact it's the model's own interpretation standing in for a decision the sponsor never actually made; flagging it preserves the sponsor's authority to correct it before the team builds against the wrong target. The scope-pressure section addresses the single most common cause of late-project conflict: without a stated-in-advance answer to 'who decides whether we cut scope or move the deadline,' that decision gets made reactively and often by whoever's loudest in a stressed conversation, rather than by whoever was actually supposed to make it.
What you get back
Goal: Ship a self-serve refund flow so customers can request and receive standard refunds without opening a support ticket. Definition of done (sharpened, needs Marcus's confirmation): customers can request a refund for any order under $200 placed within 30 days, receive automatic approval without support involvement, and see confirmation within 24 hours — orders over $200 or outside 30 days still route to support manually. Scope-pressure plan: Marcus decides whether to cut a refund type from scope; the six-week launch deadline itself does not move without the Head of Support's sign-off.
Verified against
ChatGPT GPT-5.1 · 2026-08-10
Changelog
- 2026-08-10 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
