Tool Foundation Sprint Readiness

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

Foundation Sprint Readiness

Assess whether a Foundation Sprint fits the team's current situation. Most sprints that fail were sprints that should not have been run. A 30-45 minute readiness diagnostic catches that failure mode before two days of facilitated work are spent.

Family contract: `docs/reference/skill-families/foundation-sprint-skills-contract.md`. This skill is a member of foundation-sprint-skills and conforms to the family frontmatter and Decider Checkpoint requirements.

When to Use

• A team is considering starting a Foundation Sprint and needs a fast diagnosis before committing two days.
• A founder or PM has a "should we run a Foundation Sprint?" question and wants structured input rather than a vibes check.
• An existing sprint commitment is on the calendar and the team wants to validate that prerequisites are in place.
• Re-running a Foundation Sprint after invalidated assumptions: use to confirm new context is ready.

When NOT to Use

• The team has already decided to run the sprint and just needs the brief. Use tool-foundation-sprint-brief instead.
• The team needs deep customer discovery: run customer research or problem framing first; the Foundation Sprint depends on existing customer knowledge.
• The decision is small and a full Foundation Sprint is overkill. Use a lighter prioritization or decision tool.
• No Decider is available and one cannot be appointed. Foundation Sprint requires fast strategic calls; without authority it produces options without commitment.

What This Skill Produces

A single bundled artifact with five 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 3-5 people who should be in the room, with role expectations 5. Pre-sprint activities (when verdict is Go): the prep work to complete in the days before Day 1

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:

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

Readiness Criteria (8 Canonical Checks)

The skill evaluates the team against these eight criteria, drawn from Knapp/Zeratsky (Click) and Character Capital's Foundation Sprint guide:

1. Initiative is named and concrete. The team can name the project, product area, or strategic question. 2. The stakes are meaningful. A wrong starting direction would be costly. 3. The team has existing knowledge. Real customer, market, competitor, or domain context to make informed choices. 4. The Decider is available. Strategic calls can be made during the sprint. 5. The team is small enough. No more than five core decision participants is preferred. 6. Inputs are collected. Existing research, customer examples, competitor notes, metrics are ready. 7. The output has a path to testing. The team can use a Design Sprint, experiment, customer research, or another validation method afterward. 8. The organization tolerates explicit tradeoffs. Foundation Sprint forces choosing a top bet and a backup, not preserving every possibility.

Treat the criteria as load-bearing, not a checklist to game. A team that papers over a real gap with "yes, technically" should get a Conditional Go with the gap surfaced.

Common Pitfalls

• Skipping the diagnostic because "we're going to run it anyway." This is the most common cause of failed sprints. The diagnostic costs 45 minutes; the failed sprint costs 16 hours of team time plus opportunity cost.
• Treating Conditional Go as Go without doing the prep. Conditional Go means "Go after closing these gaps." If the gaps are not closed by Day 1 morning, the sprint enters the failure mode the diagnostic was meant to prevent.
• Confusing readiness assessment with problem framing. This skill assesses whether to run a Foundation Sprint, not whether the team has the right problem. If the problem is unclear, the verdict is Wait with "do problem framing first" as the precondition.
• No Decider, no sprint. A team with no Decider available is not ready, full stop. Appointing a "Decider for the day" who lacks real authority does not solve this.
• Cargo-cult readiness. Reading the criteria and answering yes to all eight without checking does not produce readiness. The skill's value is in the honest diagnosis.

Canonical Sources

• Knapp, J., and Zeratsky, J. Click: How to Make What People Want. Foundation Sprint readiness guidance.
• Character Capital. "Foundation Sprint guide." https://www.character.vc/guide/foundation-sprint
• Design Sprint Academy. "Foundation Sprint readiness criteria for enterprise." Used for the enterprise-context adjustments to canonical readiness.

Cross-Skill Usage

This skill is the entry point of the foundation-sprint-skills family. It has no prerequisites (the metadata.prerequisites field is intentionally empty).

When the verdict is Go, the natural next invocation is tool-foundation-sprint-brief to set up the sprint logistics. When the verdict is Wait, the team typically does prerequisite work (problem framing, customer research) before re-invoking this skill.

tool-note-and-vote may be invoked once during the readiness conversation if the team disagrees on whether a Foundation Sprint is the right tool. In practice, this is rare; the diagnostic is usually conclusive.

Decider Checkpoint

This skill ends with a Decider Checkpoint in references/TEMPLATE.md. The Decider signs off on the verdict (Go / Conditional Go / Wait) and explicitly accepts the diagnosis. Without Decider sign-off, the verdict is advisory; with sign-off, it is the commitment that triggers (or postpones) the sprint.

Foundation Sprint Readiness Assessment: Brainshelf

A single invocation by the Brainshelf founding team. Brainshelf is a pre-seed B2C SaaS for personal book collection management. The team is divided on whether to optimize for individual collectors (private library) or social readers (community, recommendations).

Inputs Captured

Initiative description:

Brainshelf is a pre-seed B2C SaaS for personal book collection management. The founding team wants to launch a product that helps readers track what they have read and what they want to read next, but the team is divided on whether to optimize for individual collectors (private library) or social readers (community, recommendations, book clubs).

Team composition draft:

• Jamie (founder, PM; Decider candidate)
• Alex (design)
• Sam (engineering)
• Riley (customer expert; runs a 12k-follower book-blogger Discord)

Decider name and availability: Jamie, available full days May 13 and May 14 with no calendar conflicts confirmed.

Existing customer/market knowledge level (self-assessed): 7 of 10. The team has run 22 customer interviews with active readers in the last 8 weeks. Riley has deep network in social-reading. Less direct knowledge of pure private-collection users.

Existing competitor and alternative knowledge: Goodreads well-understood; paper journals and physical notebooks understood as a popular alternative; team has not yet compiled systematic notes on apps like StoryGraph, Bookly, or LibraryThing.

Logistics constraints: Two-day workshop, hybrid (Jamie and Sam in-person at Seattle co-working; Alex and Riley remote on Zoom and Miro).

Readiness Verdict: Go

The team meets the canonical readiness criteria with one addressable yellow flag (competitor research gap, closable in evening prep).

Diagnosis

The team meets seven of eight canonical readiness criteria cleanly. The single yellow flag is competitor research completeness.

Competitor and alternatives research is incomplete. Goodreads is well-understood; paper journals and physical notebooks are understood as a popular alternative; but the team has not surfaced systematic notes on apps like StoryGraph, Bookly, or LibraryThing. This gap matters because Day 1 morning Basics depends on a real competitor map; without it, the team risks generic positioning ("we are better than Goodreads") instead of differentiated positioning against the full alternative set. The gap is addressable: a 90-minute prep window the evening before Day 1 can produce one-page summaries for each missing competitor.

No other risk factors found. The team is small enough, has enough context, has a clear Decider, has a path to validation (Design Sprint planned for May 26), and is explicitly running this sprint to force a strategic tradeoff. The Go verdict is honest, not optimistic.

Recommended Preconditions

1. Compile competitor one-pagers (Riley owns; deadline: evening of 2026-05-12 by 22:00 PT). One page each for Goodreads, StoryGraph, Bookly, LibraryThing. Include: target user, primary jobs-to-be-done, monetization, why-people-leave signals. Target time: 90 minutes. Closes the Yellow on criterion 6.

Recommended Pre-Sprint Activities

1. Print or screen-share the 22 interview synthesis notes (Jamie owns; deadline: morning of 2026-05-13). For Day 1 morning reference during target customer and important problem decisions. 2. Block calendars (whole team owns; deadline: end of day 2026-05-11). No Slack, no email during sprint hours (09:00-17:00 PT) both days. 3. Prepare the room and digital workspace (Alex owns; deadline: evening of 2026-05-12). Pre-load Miro board with the canonical Foundation Sprint board template. Confirm Zoom call quality. 4. Confirm Day 2 closing time is unambiguous (Jamie owns; deadline: morning of 2026-05-13). Founding Hypothesis ratification cannot slip to Day 3; if it slips, the sprint failed to produce its output.

Recommended Attendees

No additional cameo experts recommended. The team has enough internal context.

Decider Checkpoint

Decider sign-off required before scheduling Day 1.

• [x] Jamie confirms Go verdict and accepts the diagnosis (competitor research gap).
• [x] Jamie commits to attending both full days as Decider.
• [x] Jamie acknowledges the documented precondition (competitor one-pagers by evening of May 12) and owns ensuring Riley completes it.
• [x] Jamie agrees the output should be a Founding Hypothesis ratifiable by end of Day 2.
• [x] Jamie acknowledges that the sprint will force a choice between social/community direction and personal-collection direction; the sprint does NOT preserve both paths.

Signed: Jamie (founder, PM), 2026-05-12 18:30 PT

Foundation Sprint Readiness Assessment: [Initiative name]

<!-- One-line description of the initiative the team is considering running a Foundation Sprint for. -->

Inputs Captured

Initiative description:

[The project, product area, or strategic question, as the team named it.]

Team composition draft:

• [Name] ([role]; Decider candidate)
• [Name] ([role])
• [Name] ([role])
• [Name] ([role])

Decider name and availability: [Name; full-day availability for Day 1 and Day 2; or partial availability with details]

Existing customer/market knowledge level (self-assessed): [_/10. Brief note on basis for the score.]

(Optional) Existing competitor and alternative knowledge: [Notes on what is and is not known.]

(Optional) Logistics constraints: [Date windows, location, format.]

Readiness Verdict: [Go / Conditional Go / Wait]

[One-sentence summary explaining the verdict.]

Diagnosis

[2-4 paragraphs explaining what is in place, what is missing or weak, and what is uncertain. Be specific about each yellow or failing criterion. If verdict is Go, this section should still surface any risks that justify the Go.]

[If verdict is Conditional Go: name each yellow flag explicitly and describe how it would block the sprint if not addressed.]

[If verdict is Wait: name each failing criterion and describe the prerequisite work the team should do before re-running the diagnostic.]

Recommended Preconditions (Conditional Go or Wait only)

[Bulleted list of concrete actions to close gaps. Each precondition has an owner and a target completion date.]

1. [Precondition] ([Owner]; deadline: [date]). [Why this matters; what "done" looks like.] 2. [Precondition] ([Owner]; deadline: [date]). [Why this matters; what "done" looks like.]

Recommended Pre-Sprint Activities (Go or Conditional Go only)

[Bulleted list of prep tasks to complete in the days before Day 1.]

1. [Activity] ([Owner]; deadline: [date]). [What and why.] 2. [Activity] ([Owner]; deadline: [date]). [What and why.] 3. [Activity] ([Owner]; deadline: [date]). [What and why.]

Recommended Attendees (Go or Conditional Go only)

[If cameo experts are recommended, list separately with the specific section they should attend.]

Decider Checkpoint

Decider sign-off required before [scheduling Day 1 / closing this diagnostic].

• [ ] Decider confirms the verdict and accepts the diagnosis.
• [ ] Decider commits to attending both full days as Decider (if verdict is Go or Conditional Go).
• [ ] Decider acknowledges the documented preconditions and owns ensuring they are met before Day 1 (if Conditional Go).
• [ ] Decider agrees the output of the sprint should be a Founding Hypothesis ratifiable by end of Day 2 (if verdict is Go).
• [ ] Decider acknowledges that the sprint will force tradeoffs; one strategic direction becomes the top bet and others become backup or are dropped.

Signed: [Decider name, role], [ISO date and local time]