# Coaches Solution Thesis

## Status
- Stage: draft
- Evidence level: hypothesis only

## Current Product Thesis
- Ballbox should not build a generic coach operating system first.
- Ballbox should win by solving one recurring workflow where coach operations and club/court context matter.

## Working Thesis
- If Ballbox helps a coach or coordinator handle a recurring class workflow with less manual coordination and fewer failures, then Ballbox can become the operational layer above scheduling, classes, and later availability-aware automation.

## Current Recommended Direction
- Start with student-facing `class discovery + request` under `/classes` as the current best Ballbox wedge candidate.
- Keep coach/operator coordination as the strongest adjacent wedge.
- Keep `reprogramming` as the likely stronger operational follow-up wedge once Ballbox owns more of the workflow.
- Operate student-first for the user experience of the first surface, while keeping coach pain relief as the business rationale.
- If discovery shows strong user love but clear budget/control sits with clubs or coordinators, Ballbox should pivot commercialization toward clubs/coordinators rather than forcing coach-paid SaaS.

## Why This Could Fit Ballbox
- Ballbox already has sports foundations for `Coach`, `Class`, and `OpenMatch`.
- Ballbox already has admin/operator surfaces that can evolve into operational tooling.
- ATC is the core strategic leverage behind Ballbox. The open question is integration depth and sequencing, not whether ATC matters.

## Why Student-Facing Class Discovery Is The Best Current Default
- It attacks the real coordination burden from the side where repetitive messaging starts: the student.
- It uses ATC public-read availability immediately, without blocking on admin-grade access.
- It avoids dependence on ATC professor records by keeping coaches Ballbox-local.
- It creates a clear path to future coach/operator tooling once student requests exist inside Ballbox.
- It is easy to explain: choose a slot and request a class.

## What Ballbox Is Not Doing Yet
- Not building a full coach CRM
- Not building a full club ERP
- Not assuming the first win is payments
- Not assuming the first win must depend on ATC

## Most Plausible Early Wedges
1. student-facing class discovery + request
2. coach/operator coordination workspace
3. reprogramming

## Why This Order
- Student-facing discovery uses the strongest currently available ATC surface: public-read availability.
- Coach/operator coordination is the natural next internal surface once requests flow into Ballbox.
- Reprogramming is likely stronger later, but depends on Ballbox owning more of the workflow first.

## Decision Rule For The First MVP
- choose the wedge that is:
  - most frequent
  - most painful
  - narrow enough for one loop
  - most aligned with Ballbox's ATC-driven unfair advantage without requiring impossible access depth

## Candidate First Loop
- User: student or recurring player looking for a class slot with a coach
- Job: find a viable option and submit a class request without messaging the coach manually
- Initial Ballbox value:
  - less repetitive inbound coordination for the coach
  - clearer student self-serve discovery
  - Ballbox captures demand and request state in one place
- Current extension path:
  - first read-only student follow-up under `/classes/me` is now live
  - next: coach/operator workspace under `/coaches`
  - later: reprogramming assistance

## ATC Role Hypotheses
- Base case: ATC is core to Ballbox's long-term moat and should enter product logic as soon as access level permits.
- Near-term open question: does v1 need ATC read access only, or also booking/write capabilities?
- Distribution upside remains important, but product advantage from ATC data is the primary reason Ballbox exists.

## What Would Invalidate This Thesis
- Coaches say the biggest pain is mostly commercial, not operational.
- The real buyer is the club and the workflow is broader than coach ops.
- The most painful wedge is already well solved by existing tools.
- ATC access is too shallow or too constrained to create meaningful product differentiation.

## Current Open Questions For Founder Checkpoint
- If evidence shows the buyer is the club but the user is the coach, should Ballbox still optimize v1 around user love first?

## Founder Direction Confirmed
- Current rule: `student-first` for the first product surface, with coach time-saving as the core business rationale.
- Fallback commercialization rule: if coaches love the workflow but clubs/coordinators are the realistic payer, Ballbox should pivot GTM and packaging toward clubs/coordinators.