/tool-design-sprint-brief

name: tool-design-sprint-brief
description: Pre-sprint brief that locks challenge, sprint questions, team and role assignments, customer recruiting plan, prototype medium, interview format, logistics, and success criteria before Monday of a Design Sprint. Use after the readiness verdict is Go and before Monday begins. Produces a two-page artifact the team and Decider sign off on as the contract for the next five days.
license: Apache-2.0
metadata:
  classification: tool
  version: "1.0.0"
  updated: 2026-07-04
  tool: design-sprint
  move: brief
  category: coordination
  frameworks:
    - design-sprint
    - sprint
  timebox_minutes: 75
  roles:
    - facilitator
    - pm
    - decider
    - researcher
  prerequisites:
    - tool-design-sprint-readiness
  inputs:
    - readiness verdict and recommendations
    - challenge description
    - founding hypothesis (optional; from a prior Foundation Sprint)
    - team roster
    - customer recruiting source and plan
    - format (in-person | remote | hybrid; per Ratified Decision 6)
    - logistics constraints
  outputs:
    - challenge statement and why-now
    - sprint questions
    - decider attendance windows
    - team roster with role assignments
    - customer recruiting plan
    - prototype medium decision
    - interview format
    - logistics plan
    - success criteria
  author: product-on-purpose

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Design Sprint Brief

Produce the brief that aligns the team on challenge, sprint questions, participants, customer recruiting, prototype medium, interview format, logistics, and success criteria before Monday begins. A well-built brief prevents Monday morning from opening with re-litigation of "what are we testing this week?"; a missing or vague brief almost guarantees it.

Family contract: [`docs/reference/skill-families/design-sprint-skills-contract.md`](../../docs/reference/skill-families/design-sprint-skills-contract.md). This skill is a member of `design-sprint-skills`.

When to Use

• The readiness verdict from `tool-design-sprint-readiness` is Go (or Conditional Go with preconditions cleared).
• The sprint has dates blocked on calendars and you need the artifact that names what the sprint is for.
• The team has customer recruiting active and you need to commit a recruiting plan, honorarium budget, and Friday schedule before recruiting closes.
• A skeptical exec wants to know "what is the team doing for five days plus customer cost?" and you need an answer that fits on two pages.

When NOT to Use

• The sprint has already started. The brief is a prep artifact, not an in-sprint deliverable. If Monday is happening, run `tool-design-sprint-map-and-target` instead.
• The readiness verdict is Wait. The brief cannot fix an unready team; close the preconditions first, then re-run readiness, then invoke this skill.
• The team wants a stakeholder strategy document. The brief is internal prep, not an external deliverable. If a stakeholder document is needed, that is a downstream artifact (the Friday scorecard or the next-step memo).
• Customer recruiting has not started. The brief locks the recruiting plan but cannot replace the recruiter. If no recruiter is named, go back to readiness Wait verdict.

What This Skill Produces

A single bundled artifact with nine sections:

1. **Challenge statement and why-now**: one paragraph naming the testable challenge and the urgency that justifies a sprint this week vs. later. 2. **Sprint questions**: 2-4 specific questions the Friday testing answers. The highest-risk assumption from any prior Foundation Sprint becomes the lead question. 3. **Decider attendance windows**: the load-bearing moments (Mon AM, Wed AM, Fri PM at minimum); fully blocked if available. 4. **Team roster with role assignments**: who is in the room each day and what role each person plays through the week. 5. **Customer recruiting plan**: target profile, source, count, incentive, recruiter owner, recruiting deadline, Friday schedule. 6. **Prototype medium decision**: clickable, slideware, service role-play, paper, physical mock, or other; with rationale. 7. **Interview format**: live or remote; moderated or unmoderated; recording and consent posture; observer-room setup. 8. **Logistics plan**: dates, hours, location, format (in-person, remote, hybrid), tools, daily rhythm. 9. **Success criteria**: observable outcomes that mark the sprint successful or not.

See `references/TEMPLATE.md` for the canonical structure and `references/EXAMPLE.md` for the Brainshelf book-catalog brief.

Inference Inputs

| Input | What the skill does with it | |---|---| | Readiness verdict and recommendations (from `tool-design-sprint-readiness`) | Pulls the recommended attendees, customer recruiting plan, pre-sprint activities, and prototype medium proposal; flags any precondition that has not been closed | | Challenge description | Compresses into the Challenge Statement and derives 2-4 sprint questions | | Founding Hypothesis (optional; from a prior Foundation Sprint) | The highest-risk assumption from the FS scorecard becomes the lead sprint question; the top bet becomes the design direction; the backup becomes the fallback decision if Friday invalidates | | Team roster | Maps people to the required Design Sprint roles (Decider, Facilitator, PM, Design, Engineering, Researcher or Customer Expert); confirms 4-7 person band | | Customer recruiting source and plan | Locks recruiter owner, target profile, source channel, honorarium budget, deadline, and Friday schedule | | Format (in-person, remote, hybrid; per Ratified Decision 6) | Branches the brief body where format affects authoring: recruiting plan (in-person requires geo-local cohort; remote allows cross-timezone), prototype medium (some media work better in-person; e.g., physical mock), interview format (live vs remote moderated), observer setup (in-room vs Zoom breakout room) | | Logistics cons