Skip to content

End-to-End Case Study - USA Clay Target

Purpose of This Case Study

This case study documents a complete, real-world run of Feedback Loops from an initial Pain Point Entry (PPE) through multiple Product Requirements Documents (PRDs) generated from a single operational problem.

It reflects what actually happened once the work was done - not what was imagined at the outset.

The case study is intentionally:

  • grounded in day-to-day operations
  • constrained by time, people, and seasonality
  • uneven in urgency across outcomes
  • disciplined about stopping points

This is not a story about transformation or modernization. It is a story about reducing business risk without inventing solutions too early.

The case study intentionally stops at approved PRDs. That is not an omission - it is the point.

Company Context - USA Clay Target

USA Clay Target is a real organization that operates a seasonal competitive clay shooting program.

A core business function is weekly season scoring, which must be executed reliably every Saturday night during the active season.

This process:

  • is business-critical
  • is time-sensitive
  • has reputational impact
  • directly affects league participants

Failure or delay is immediately visible.

The Actual Situation

For years, season scoring was executed manually by one person.

Jim held multiple roles simultaneously:

  • IT Director
  • Product Owner
  • Project Manager
  • Database Administrator
  • Support
  • and several others

Every Saturday night around 9pm, Jim ran the full season scoring process end to end.

No one else:

  • understood every step
  • had access to all required systems
  • could execute the process confidently
  • was accountable for the outcome

Nothing was "broken." Scoring ran on time. Results were published. The system worked.

And yet the organization was structurally fragile.

If Jim was unavailable, the business was exposed.

What This Case Study Actually Shows

Rather than jumping straight to automation or tooling, the team deliberately slowed down and applied Feedback Loops with discipline.

Across the stages, the team:

  • documented the problem without proposing solutions
  • validated risk with evidence rather than intuition
  • justified investment without manufacturing urgency
  • decomposed one problem into multiple, separable outcomes
  • made explicit funding and deferral decisions
  • produced four independent PRDs from a single initiative

Some outcomes were approved for immediate delivery. Others were deliberately deferred - and documented anyway.

That combination is what makes this case study realistic.

Where This Case Study Stops

This case study stops after approved PRDs.

At that point:

  • the problem is stable
  • scope is explicit
  • trade-offs are recorded
  • requirements are testable

Everything that follows - workflow refinement, domain modeling, implementation - is execution.

Important work, but not decision-dense work.

Why This Matters

Most teams rush past this phase and hope experience will save them later.

Experience usually arrives as rework.

This case study shows what happens when teams do the thinking first - and stop when thinking is done.