Six weeks into building the Protocol coach dashboard, I stopped.
Not because it was technically difficult. Not because the idea was wrong.
I stopped because I looked at what I was actually building and realised I was solving a problem for an audience I had not validated, while the audience I had already built for was sitting there underserved.
What I was building
Protocol started as an athlete tool. A training OS: state-aware, designed around how training actually works rather than how compliance dashboards assume it does.
The athlete side is live at useprotocol.app.
The coach dashboard felt like the logical next step. Coaches work with athletes. Coaches need to track athlete data, assign programming, and monitor progress. If Protocol already captures athlete data, building a coach view on top of it seems obvious.
On paper.
Where it went wrong
The coach dashboard is not a view on top of the athlete tool.
It is a different product with a different user, different workflows, different data requirements, and a different commercial model.
Coaches do not just want to see what athletes are doing. They need to manage multiple athletes at the same time, communicate with them, adjust programming in response to what they see, and coordinate across a roster that may have twenty people at different stages of training.
That is not a dashboard.
That is a platform.
I was building it for an audience, coaches, who had never told me they wanted this. I had spoken to athletes. Athletes use Protocol. Coaches were still theoretical.
The trap I walked into
This is a classic product mistake.
You build something. It works. You can see the adjacent problem. That adjacent problem has a logical connection to what you already built.
So you start building for it before you have validated that the person with the adjacent problem wants your solution, will pay for it, or even experiences the problem the way you imagine.
You end up building two products at the same time. Neither gets your full attention. The one you validated gets slower. The one you have not validated accumulates assumptions that still need to be tested later.
I have watched this happen inside product teams I worked with.
Then I did it myself.
The decision
Stop the coach dashboard. Return to the Protocol athlete side. Validate and monetise that before building for a second audience entirely.
This is not giving up on the coach product. It is sequencing correctly.
The athlete side has to become strong enough, and commercially proven enough, to justify a different product for a different user with a different set of needs.
If coaches want Protocol, they will tell me. They will arrive at the athlete tool and ask for a way to manage their athletes inside it.
That signal is worth waiting for.
What the decision cost and what it saved
Cost: six weeks of build time on an architecture I paused. Some of that work transfers. Some of it does not.
Saved: an indefinite period of building for an audience I had invented.
The sunk cost would have grown. The validation would not have arrived. Eventually I would have had to make the same decision with more work to abandon.
Better now.
What this reveals about scope
Scope discipline is the product skill that gets hardest to maintain once the product starts working.
When nothing is working, scope is constrained by survival. You build what users need or you do not survive.
When something starts working, the constraint loosens. You can see adjacent problems. You have the energy to pursue them. The pressure to prove the first thing feels lower.
That is when the classic mistakes happen: feature bloat, second audience, platform creep.
The discipline is staying inside the boundary of what you have validated until you are certain it is ready to extend. Not forever. Long enough to actually know what you are building and who it is for.
Protocol is an athlete tool. That is what I am building.
When it is validated commercially, I will know what the right next step is. It will be informed by something stronger than my own logic about what coaches probably want.
Protocol is live at useprotocol.app. Free to use.
Moe Hachem is a Product, UX & Operations Consultant based in Dubai. mghachem.com