When I started building Protocol, I had a clean assumption: coaches manage athletes through programs.
Build the program. Assign it. Let the athlete follow it. Monitor progress.
Clean. Linear. Easy to model in software.
Wrong.
Not completely wrong, but wrong enough that the assumption shaped the first version of Protocol in ways that took months to unwind.
What I assumed about coaching
The model I was building from was top-down. The coach designs the plan. The athlete executes it. The coach adjusts based on output data.
Most training software follows that model. Structured programs, assigned workouts, completion tracking, performance graphs. The coach sits above the system. The athlete feeds data into it.
That model makes sense if you have never trained seriously with a coach. It also makes sense if you have, but forgot what the conversation actually feels like.
What building the product revealed
I am an athlete. I have trained seriously for years across running, structured blocks, and cycles of personal data. I started using Protocol to track my own training while I was building it.
The mismatch showed up quickly.
I do not review a training week as a completion percentage. I review it as a conversation with what my body is doing. What felt heavy that should not have. What moved well when I expected it to feel bad. What the gap between the prescribed and the actual says about recovery, stress load, and readiness.
Coaches do the same thing with athletes.
The program is a starting point. The real work is reading the signal inside the deviation.
Software built on the linear model does not give you that. It gives you a compliance dashboard: hit rate, missed sessions, performance trends.
Useful data. Wrong question.
The architecture decision this forced
The difference between a compliance dashboard and a coaching tool is state awareness.
A compliance dashboard asks: did it happen?
A coaching tool asks: what is the athlete's current state, and what does that mean for what comes next?
Those are different products. They need different data models, different views, and different logic for how the system responds when something deviates from plan.
Building Protocol from my own training data made this obvious fast. When I missed a session, I did not want the software to mark it red. I wanted it to help me understand why, then tell me what that meant for the next three days.
That is a state problem.
The athlete has a state: readiness, fatigue, recovery, form. The system has to model that state, not just log the absence.
That is what I mean when I say coaching logic and training software do not match. Most training software is built to manage compliance. Coaching is built to manage state.
What this changed about Protocol
The rebuild was not cosmetic.
The data model changed. The view logic changed. The way Protocol thinks about an incomplete workout changed too: not as a miss, but as a signal with a reason.
Protocol is still being built. useprotocol.app is live with the athlete side. The logic I am describing here is what the next phase is built on.
The assumption I started with was not useless. It got me to the question faster than any amount of user research would have.
It was still an assumption.
The gap between what I assumed and what training actually felt like from the inside became the product.