Case Studies
These case studies show Feedback Loops in practice, not in theory.
They are intentionally: - imperfect - constrained - people-dependent - occasionally uncomfortable
Each one demonstrates a different failure mode - and what changes when you apply discipline at the right point in the process.
This is not success theatre. It’s recognition-based learning.
Case Study #1 - Eclectic Cheese Shop
How Not to Do Things Properly
A deliberately absurd, Monty Python–esque case study designed to make one point unmistakably clear:
When problems are poorly understood, organisations respond with noise instead of action.
You’ll see the same problem play out three different ways:
1. Chaos and misinterpretation
2. Partial structure with bad assumptions
3. Clear thinking that actually moves things forward
This case study is short, memorable, and intentionally ridiculous - because bad problem handling often is.
What this one teaches - Why jumping to solutions creates nonsense - How miscommunication compounds as problems move “up” - What clarity looks like by contrast
Case Study #2 - HarborView Services
The Professional Failure
A more grounded scenario familiar to most IT teams:
“Can you add a button that does the thing we talked about last month?”
This case study explores what happens when work begins without a stable problem definition - and how teams end up shipping something that technically works while still failing the business.
It’s funny in a painful, recognisable way.
What this one teaches - How vague requests turn into expensive rework - Why “just build it” feels fast but isn’t - What breaks when decisions are never actually made
Case Study #3 - USA Clay Target
A Full Green-Path Run (PPE → PRDs)
A real organisation. A real operational risk. A real mess.
This end-to-end case study walks through a clean, disciplined run of Feedback Loops, from the initial Pain Point Entry through multiple PRDs generated from a single problem.
No heroics.
No transformation narrative.
Just correct thinking under real-world constraints.
The case study intentionally stops at PRDs - because once requirements are stable, the remaining work is execution.
What this one teaches - How one problem produces multiple outcomes - Why multiple PRDs are normal (and healthy) - How to make funding and deferral decisions explicit - Where Feedback Loops is designed to stop
How to Read These
You don’t need to read these in order.
- Start with Eclectic Cheese Shop if you want the intuition.
- Start with HarborView Services if you want recognition.
- Start with USA Clay Target if you want depth.
All three point to the same conclusion:
Most delivery problems are decision problems - and they show up long before code is written.