Six weeks into building the Protocol coach dashboard, I stopped.
The idea was still credible, and the build was technically fine. I stopped because I looked at what I was actually doing and realized I was building for an audience I had not validated, while the audience I had validated was sitting there underserved, waiting for me to finish being distracted by the more interesting problem.
What the coach dashboard was
Protocol started as an athlete tool: state-aware, built around how training actually works, and focused less on compliance tracking than on signal reading. The athlete side is live at useprotocol.app.
The coach dashboard felt like the logical next step. Coaches work with athletes. If Protocol captures athlete data, the coach view seems to follow naturally.
On paper, that is true.
In reality, the coach dashboard is not just a view on top of the athlete tool; it is a different product, a different user, and a different mental model. A coach managing twenty athletes has completely different requirements from an athlete managing their own training.
That makes it a second product with a shared data layer.
The trap
I have seen this pattern in product teams many times. The core product starts working, the adjacent problem becomes visible, and the connection looks obvious enough that the team starts building toward it.
The question that gets skipped is whether the adjacent user actually wants that solution now.
I had spoken to athletes, and athletes use Protocol. Coaches were theoretical, a market I had reasoned myself into believing existed in the exact form my dashboard imagined. Six weeks of coach-dashboard development became six weeks of building for a hypothesis I had not tested.
This is the founding failure of second-product syndrome: the confidence earned from the first validation leaks into the second idea and starts masquerading as evidence.
What stopping cost
Stopping cost six weeks of build time. Some of the architecture transfers to future work, and the data model is more extensible because of it. Still, the specific UI work, coach-specific logic, and onboarding flows for a user type I do not yet have are paused.
The bigger cost was the athlete side, which had been in maintenance mode while I was working on the dashboard. Features I wanted to ship for the validated user were delayed because I was building for the unvalidated one.
The real cost of second-product syndrome is the neglected validated product, not only the abandoned work.
What scope discipline actually means
Scope discipline is harder when something is working than when it is failing.
When a product is struggling, scope is constrained by survival. You build what the user needs or the product does not survive. When there is signal, growth, and a problem that clearly exists, the constraint loosens. You can see more, you have energy to pursue more, and the pressure to stay focused feels lower.
That is exactly when mistakes happen.
The discipline is staying inside the boundary of what has been validated until there is a real reason to extend it. Coaches might love Protocol, or they might not. The athlete side needs to be commercially validated before I spend another six weeks finding out.
Returning to the athlete side means sequencing the coach product correctly.
When Protocol is proven with athletes, when the commercial case is established and I understand the product deeply enough to know what a coach view actually needs, I will have a real foundation for that second product.
Until then, the coach dashboard is a hypothesis in a folder, not deleted, just waiting for evidence.
Protocol is live at useprotocol.app.
Built by Moe Hachem. mghachem.com