/tool-design-sprint-readiness

name: tool-design-sprint-readiness
description: Pre-sprint diagnostic that determines whether a team should run a Design Sprint now, postpone it, or do prerequisite work first. Produces a Go / Conditional Go / Wait verdict with diagnosis, recommended preconditions, attendee list, customer recruiting plan, and pre-sprint activities. Use when a team is considering starting a Design Sprint and wants a fast yes/no diagnosis before committing five days of team time and customer recruiting cost.
license: Apache-2.0
metadata:
  classification: tool
  version: "1.0.0"
  updated: 2026-07-04
  tool: design-sprint
  move: readiness
  category: coordination
  frameworks:
    - design-sprint
    - sprint
    - character-note-and-vote
  timebox_minutes: 45
  roles:
    - facilitator
    - pm
    - decider
  prerequisites: []
  inputs:
    - challenge description
    - existing hypothesis (from Foundation Sprint or other source)
    - customer access status
    - decider availability
    - team composition draft
  outputs:
    - readiness verdict
    - diagnosis
    - recommended preconditions
    - recommended attendee list
    - customer recruiting plan
    - pre-sprint activities
  author: product-on-purpose

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

Design Sprint Readiness

Assess whether a Design Sprint fits the team's current situation. Design Sprint failure modes are expensive: five consecutive days of a 4-7 person team, plus customer recruiting cost (typically 5 strangers paid honoraria), plus the prototype build. A 30-45 minute readiness diagnostic catches the failure modes before that commitment is made.

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` and conforms to the family frontmatter and Decider Checkpoint requirements.

When to Use

• A team is considering starting a Design Sprint and needs a fast diagnosis before committing five days plus customer recruiting effort.
• A team has just completed a Foundation Sprint and is deciding whether the next test should be a Design Sprint, a smaller experiment, or direct build. The Founding Hypothesis is consumed as optional input context (no separate bridge skill artifact is required).
• An existing sprint commitment is on the calendar and the team wants to validate that prerequisites (Decider, customers, prototype medium) are in place.
• Re-running a Design Sprint after an inconclusive first sprint: use to confirm the new challenge framing and customer access are ready.

When NOT to Use

• The team has already decided to run the sprint and just needs the brief. Use `tool-design-sprint-brief` instead.
• The team has no clear challenge and is still in discovery. Run problem framing or a Foundation Sprint first; a Design Sprint depends on a sprint-worthy challenge.
• Low-stakes tweaks where five days of team time would be disproportionate. Use a lighter experiment design instead.
• No customer access for Friday testing and no realistic recruiting plan. A Design Sprint that cannot test on Friday is just a four-day workshop with no learning event.
• No Decider available and one cannot be appointed. Design Sprint requires fast decisions Wednesday and pre-test Thursday; without authority the sprint produces options without commitment.

What This Skill Produces

A single bundled artifact with six sections:

1. **Readiness verdict**: Go / Conditional Go / Wait 2. **Diagnosis**: what is in place, what is missing, what is uncertain 3. **Recommended preconditions** (when verdict is Wait or Conditional Go): the prerequisite work the team should do before the sprint 4. **Recommended attendee list** (when verdict is Go or Conditional Go): the 4-7 people who should be in the room, with role expectations 5. **Customer recruiting plan** (when verdict is Go or Conditional Go): target profile, source, count, incentive, recruiter owner, recruiting deadline (typically 7-10 days before Friday) 6. **Pre-sprint activities** (when verdict is Go): the prep work to complete in the days before Monday

See `references/TEMPLATE.md` for the canonical structure and `references/EXAMPLE.md` for a worked example using the Brainshelf book-catalog thread.

Inference Inputs

The skill runs an inference pass over these inputs to produce the verdict:

| Input | What the skill does with it | |---|---| | Challenge description | Determines whether the challenge is sprint-worthy (specific enough to prototype in 4 days; big enough to justify 5 team-days) | | Existing hypothesis (from Foundation Sprint or elsewhere) | Confirms there is a testable bet, not exploratory discovery. Highest-risk assumption from the FS scorecard becomes a candidate sprint question | | Customer access status | Critical. Without realistic Friday customer access, the sprint cannot test | | Decider name and full-week availability | Confirms Decider can attend at least Monday morning, Wednesday morning (heat map + supervote), and Friday afternoon (Decider review); ideally all 5 days | | Team composition draft | Checks roster against the 4-7 person band; flags missing roles (engineering for prototype build, design for sketching, researcher or PM for customer interviews) | | Prototype medium feasibility | Confirms a 1-day prototype is achievable in the chosen medium (clickable, slideware, service role-play, paper, physical mock) | | (Optional) Logistics constraints | Confirms five consecutive days can actually be cleared by all attendees |

If a load-bearing input is missing or low-confidence, the skill flags it explicitly and proposes how to close the gap before Monday.

Readiness Criteria (8 Canonical Checks)

The skill evaluates the team against these eight criteria, drawn from Sprint (Knapp, Zeratsky, Kowitz), GV "Is Your Idea Sprint-Worthy?", and Character Capital's Design Sprint guide:

1. **Chal