Protocol is teaching me that training software is less about logging events and more about understanding state.
I have been using Protocol to track my own training for months, not as a beta tester, but as an athlete who builds the tool he needs and then has to live with it.
That is the clearest possible feedback loop. If Protocol does not work for how I actually train, I know immediately because I am the person trying to use it.
What it has taught me is not primarily about features or UI. It is about the fundamental question the product is trying to answer, and whether the question I started with was the right one.
The data I actually generate
A training session produces obvious data: distance, duration, pace, power output if you are using a meter, and perceived effort if you are rating it. This is the layer most training tools capture. It is useful. It is also incomplete in a way that matters.
The data I find myself wanting to record is not just what happened. It is the relationship between what happened, what was supposed to happen, and what that relationship tells me about where I am.
A session where I hit my target splits but felt terrible is a different data point from a session where I missed my targets but felt controlled and strong. The number looks worse in the second case. The signal may be better.
State data is the layer that makes the logged data interpretable: how the session felt, what perceived effort was relative to actual output, and what my legs were doing three days after a hard block.
Without it, the log is a record; with it, the log starts to become a pattern.
What this revealed about the product
Most training software is built to capture the record: session happened, metrics logged, performance graphed. The layer that makes the record interpretable gets added informally in the notes field, if the athlete bothers.
Most athletes do not bother with a notes field because it feels like homework, and the product does not make it feel like part of the session.
What I am building toward in Protocol is a state layer that feels like a natural part of logging, not an additional step. The question after a session is not only "what did you do?" It is "how was it?" The answer should be as fast to record as the session itself.
The design challenge is making state input feel like conversation rather than form. A slider that captures perceived effort is faster than a text field. A prompt that asks a specific question, such as "how did that feel relative to yesterday?", produces more useful data than an open notes field.
This seems obvious in retrospect, but it was not obvious when I started building.
The pattern I kept misreading
For about six weeks, I was logging consistently and noticing that my perceived effort was running high relative to my output. Sessions that should have felt comfortable were feeling hard. I was attributing it to accumulated fatigue from a training block.
When I mapped the state data against the training load over that period, the pattern was different. The perceived effort spike started three days before I had increased the load, not after. It was a readiness signal, not a fatigue response. My body was telling me something was off before the training gave it reason to be.
I was misreading it because I was looking at individual sessions; the state data only made sense across the sequence.
This is what I mean when I say Protocol is a state management problem, not a compliance tracking problem. The single session's data is almost never the most important thing. The relationship between sessions, the trajectory, the pattern, and the deviation, is where the useful information lives.
What this means for the product architecture
Designing for states rather than events changes what the data model needs to capture, how it relates sessions to each other, and what the product surfaces when you look back.
An event-based model asks: did the session happen, and what were the metrics?
A state-based model asks: what was the athlete's state going into this session, what was it coming out, and how does that relate to the trajectory they are on?
The second question requires more data, more relationship logic, and a product that makes it easy, not burdensome, to record the state layer alongside the event.
Protocol is being built toward that model. The athlete side is live at useprotocol.app, and the state layer is partial: better than most, not yet where I know it needs to be.
What my own training data keeps confirming is simple: the question the product is trying to answer is right, and the implementation is still iterating toward it.
Built by Moe Hachem. mghachem.com