For the last eight months or so, Peter, my business partner at ClockWork League, and I have been doing two things at the same time.
We have been working out a coaching methodology for creative agencies - the framework, the assessments, the underlying theory of why agencies get stuck where they do. And we have been building the software that will eventually carry it. Not in sequence. In parallel. Some days the methodology pulls the software. Other days the software pulls the methodology. Most days they pull each other, and the work is the back-and-forth between them.
This is not a normal way to build a coaching business. The normal way is to develop the methodology first - through years of consulting, books, and live workshops - until it is stable enough to be productized. Then someone, usually not the founders, builds a platform around it. The platform is delivery infrastructure. The methodology is the product.
We are doing the opposite. The platform is part of the methodology, and the methodology is shaping the platform. Neither one has come first. They are emerging together, and the structure of the work is teaching us something about both.
The software question every coaching business reaches
There is a specific moment, in any coaching business that scales, where the founders have to decide what to do with the software question.
For a long time, the answer was simple. Most coaching businesses had no software. They had decks, worksheets, sometimes a private community on a third-party platform, occasionally a course on Teachable, Kajabi or Skool. The actual coaching happened in calls. The actual methodology lived in the coach's head and in their slides, or in some cases a book. The software, if it existed at all, was decoration around the real product.
That has been changing. AI has changed it specifically. A coaching methodology that lives only in the coach's head cannot scale beyond the coach's calendar. A methodology that lives in software - properly structured software, not a course platform - can scale in ways the coach alone never could.
But that requires answering a harder question than most coaches want to answer. What does it mean to put a methodology into software? Not the materials. The methodology itself. The decision-making, the diagnosis, the sequencing, the situation-specific judgment that an experienced coach applies in real time. Can that even be put into software, or does the software inevitably flatten it into something less useful than what the coach does?
The honest answer is that most attempts to do this fail. They fail in a specific way. The software ends up being a delivery wrapper around content that could just as easily live in a Google Drive folder. Videos behind a login. Worksheets you download. Progress bars that track completion rather than transformation. The methodology, where it exists at all in the software, sits in the form of unstructured copy that the user reads, makes their own interpretation of, and applies inconsistently - if they apply it at all.
That is what we are trying to avoid.
An operating environment is not a course
The thesis we have been building toward is that a coaching methodology, properly translated, is not a course. It is closer to an operating system for a particular kind of business. The agency owner using it does not consume content. They run their business through a structured environment that knows their situation, holds their decisions, tracks their evidence, and shapes what happens next based on what they actually do.
That is a different category of product than a course.
A course teaches. The user reads, watches, takes notes, and is meant to apply the ideas to their business themselves. The work of translation lives entirely on the user's side. The content provider trusts that the user will do the work and rarely has visibility into whether they did. Most users do not. Most courses produce a small percentage of high performers who would have figured it out anyway, and a large percentage of buyers who consumed the material and changed nothing.
An operating environment does not teach. It structures. The user works through the environment, which has been built around a specific operating model for how an agency runs. The environment captures inputs, tracks state, holds decisions, surfaces what should happen next. The methodology is not delivered. It is enacted. The user is not the one doing the translation. The system is.
This is harder to build than a course. It is also a fundamentally different kind of intervention. A course gives you knowledge and hopes you apply it. An operating environment gives you a place to run your business while we hold the structure around you.
The architectural question is whether the methodology can be expressed cleanly enough to inhabit software in this way. That is what the last eight months have been about.
Each one refuses the other's vagueness
What we have been discovering, in the actual work of building, is that the methodology and the software constrain each other in useful ways.
When we try to put a piece of the methodology into software, the software refuses to accept anything that has not been thought through clearly. A vague concept stays vague until somebody decides what it means in operational terms. A hand-wavy assessment becomes a structured set of fields, each of which has to be defined, scored, and connected to specific decisions. A piece of advice that sounded fine in a coaching call has to become a rule that the software can apply consistently.
This is uncomfortable work. It exposes parts of the methodology that were not as clear as we thought they were. Often, the act of trying to put something into software is what teaches us what the methodology actually is.
The reverse is also true. Sometimes the software wants to do something that the methodology does not yet support. The architecture suggests an interaction, or a flow, or a capability, that would be useful if the underlying coaching logic existed for it. So we have to develop the coaching logic to fill the gap. The software becomes a way of generating new questions for the methodology that we would not have asked otherwise.
Building both at once means we cannot pretend the methodology is more complete than it is. It also means we cannot pretend the software is more capable than the methodology can responsibly support. The two systems keep each other honest.
There is a second consequence of building this way that we did not anticipate.
The by-product we did not plan for
A methodology that has been translated into software accumulates evidence in ways that pure coaching cannot. Every assessment a user completes, every decision they record, every artifact they produce, every outcome they hit or miss, becomes structured data the system can learn from. Over time, that data tells us things the methodology alone would not have revealed.
Which interventions actually move agencies forward, and at what stage. Which assumptions in our theory hold up across many businesses, and which break in specific conditions. Which wheels of the model produce the largest changes, and which produce smaller ones than we expected. Which sequences of work compound, and which produce isolated improvements that do not stick.
Pure coaching produces this kind of learning slowly, through experience, mostly in the coach's head. The coach gets better over time, but the learning is mostly tacit and largely lost when the coach retires or moves on. Software-mediated coaching produces the same learning faster, more explicitly, and in a form that can be revised, shared, and built upon.
That is not the reason we are building this way. We are not optimizing for data. We are building this way because we believe the methodology works better when it inhabits software, for the agencies using it. The data is a by-product. It happens to be a valuable by-product, but it is downstream of the actual goal, which is that agency owners reach the other side of being stuck in ways they could not have reached with content alone.
I am writing this article partly because the work has been unusual enough that it is worth describing, and partly because there is a broader pattern underneath it that I think applies to other domains.
The same translation is coming for other domains
Anywhere that expert judgment has been delivered through coaching, consulting, or training, there is now a question about whether that judgment can be partially translated into software. Not replaced. Translated. The coach does not disappear. The consultant does not disappear. The trainer does not disappear. But the parts of their work that can be structured, captured, sequenced, and run as a system - those parts move into software, while the human judgment focuses on what only the human can do.
This is the same pattern as the agency-services-to-product translation that has been happening in our industry for years. It is the same pattern as the law-firm-to-software translation that is now happening in legal. It is the same pattern as the doctor-to-clinical-decision-support translation that has been happening in medicine for longer. The expertise stays. The delivery shape changes.
What we are building for agencies is one instance of a broader shift. Expert work, when translated honestly, produces software that is different in kind from a course or a content library. It is closer to an operating environment that holds the expertise while the user runs their business through it.
The hard part is not the technology. The technology has been ready for a while. The hard part is the translation.
Nearly everything we have worked on is the translation, not the code. The code, as it usually does, follows.