Most training software is built around a question it never asks out loud: did the athlete do the thing?
The answer is a boolean. Done or not done. The feature set that follows is predictable: program assignment, workout completion, progress graphs trending upward.
Clean. Logical. Wrong for the problem it is supposed to solve.
Training is not a compliance problem. It is a state management problem.
The question the software should be asking
An athlete on a training program is not in one of two states. They are in a continuous set of overlapping states: fatigue, readiness, adaptation, recovery. Those states change daily, sometimes hourly, and interact in ways no simple progress graph captures.
A well-designed training week for an athlete in high fatigue looks completely different from the same week for an athlete who is fresh and primed.
The program is the same. The application of it is different.
A coach who is paying attention knows this and adjusts. Software built around compliance does not, because it only tracks whether the thing happened. It does not track what state the athlete was in when it happened or did not.
I use Protocol to track my own training. I have for months. The data I generate is not just performance data. It is state data: how a session felt relative to how it was supposed to feel, where the deviation was, what it might mean, and what the next 72 hours probably look like given what the last 72 produced.
This is the data that actually drives training decisions.
Standard training software usually ignores it or buries it.
What this meant for Protocol's data model
When the product is built around compliance, the data model is simple. Session scheduled, session completed, metrics logged. The relationships between data points are linear.
When the product is built around state, the data model changes.
A session is not just an event. It is an observation inside a state trajectory. What matters is not only that it happened, but where it sits in the athlete's recent history and what it adds to the pattern.
This changes the schema. It changes what gets stored, what gets surfaced, and what the product needs to reason about when a session deviates from plan.
A missed session in a compliance model is a red mark.
In a state model, it is a signal. The athlete may have been right to skip it. They may have been wrong. Either way, the product should help distinguish between the two instead of simply marking the absence.
What state-aware design requires
Building for state means making implicit things explicit.
Fatigue is implicit. You feel it. You do not log it the way you log a workout.
Readiness is implicit. The relationship between yesterday's training load and today's performance is implicit.
Making those things explicit in a product means designing input mechanisms that do not feel like logging. Nobody wants to complete a form about how their legs feel. They might, however, respond to a product that treats the check-in like a conversation rather than data entry.
This is still what Protocol is working toward. The athlete side is live. The state awareness is partial: better than most training tools, not yet where it needs to be.
What I am certain of is the direction.
The product that wins in this space is not the one with the most features. It is the one built around the right question.
Did you do the thing is the wrong question.
How are you, and what does that mean for what comes next?
That is the product Protocol is moving toward.
useprotocol.app is live and free. Built by Moe Hachem - mghachem.com