Note
July 7, 2026
2 min read
Stop Optimizing for Almost
By Cristiano Pierry
A team can become consistently late without any single delay feeling serious. The cost is the learning that starts only after release.
There are six people in my family, which means I live inside a small, recurring case study on time management.
My youngest and I are usually on time. My oldest is often 5 to 15 minutes late. Not “send a search party” late. More like arriving for dinner 12 minutes late or emerging at 3:11 for a 3:00 departure, somehow surprised that time continued moving.
The consistency is what makes it interesting.
If you are always 5 to 15 minutes late, you probably could be on time. You have optimized for “almost.”
Product teams can settle into the same pattern. No single delay looks serious. The release waits for one more feature, edge case, alignment meeting, polish pass, or quick validation. Each decision sounds responsible on its own.
The cost appears in the learning that has not started. A small release could test the riskiest assumption while the team continues improving everything around it. Waiting may still be the correct decision when the downside is consequential or the signal would be misleading. But “one more thing” is not a quality standard.
When a team delays, it should be able to name what evidence the extra time will produce. Otherwise, 3:15 has quietly become the plan.
This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.