What a DNF Taught Me About Shipping Products

DNF means “Did Not Finish.” In endurance sports, it is the three letters every racer dreads. You trained for months, paid the entry fee, showed up at the start line, ran for hours, and then — you stopped. You did not cross the finish line.

My first DNF happened at kilometer 32 of a 42-kilometer race. My legs had been sending warnings since kilometer 25, but I kept pushing. By kilometer 30, the warnings turned into demands. By 32, my right calf seized completely. I stood on the side of the road, one hand on a barrier, watching other runners pass me, and made the call.

I dropped.

The walk to the medical tent felt longer than the race itself. I spent the entire time cycling through the same questions: Could I have prepared better? Should I have slowed earlier? Was there a version of this race where I finished?

Three months later, I killed a product feature at work. The parallels were uncomfortable.

The feature that should have stopped earlier

We had been building a seller analytics dashboard for two months. The spec was clean. The engineering team was executing well. Early internal feedback was positive. But as we got closer to launch, the usage projections kept getting revised downward. The sellers we had interviewed during discovery were enthusiastic, but the broader seller population showed weak intent signals in our pre-launch survey.

I kept pushing. We had momentum. The team was invested. The code was nearly done. Stopping felt like waste.

Then I ran the numbers honestly. Projected monthly active users: low. Projected impact on seller retention: marginal. Projected maintenance cost: ongoing. We were about to ship a feature that would cost more to maintain than it would generate in value.

I killed it. The team was frustrated. I was frustrated. Two months of work, shelved.

The lesson from both

The DNF and the killed feature taught me the same thing: the decision to stop is a skill, not a failure. And the cost of stopping late is always higher than the cost of stopping early.

In the race, I could have dropped at kilometer 25 when the first warnings came. I would have walked away with tired legs instead of a seized calf that took six weeks to heal. I pushed seven more kilometers trying to prove I could finish, and those seven kilometers cost me six weeks of training.

With the feature, we could have run a validation sprint in week two instead of month two. A quick prototype to five sellers would have shown us the weak demand signal before we had written thousands of lines of code.

Both cases suffered from the same bias: sunk cost momentum. I had already invested, so stopping felt like losing. But continuing was the real loss.

What I do differently now

In training, I respect the body’s warning signals. A tight calf at kilometer 10 of a long run means I shorten the run. I do not push through to prove a point. The training plan is a plan, not a contract.

In product, I build kill criteria into every initiative before we start building. “If [metric] does not reach [threshold] by [date], we stop.” Writing the exit condition upfront makes it easier to execute when the time comes, because the decision was already made. You are not killing the project in the moment of pressure. You are following a protocol you agreed to when you were calm.

Both practices require the same muscle: the willingness to look at data honestly and act on what it says, even when the emotional momentum is pulling you forward.

That is what a DNF teaches you. Not that you failed, but that you learned to read the signals.