Note
July 7, 2026
2 min read
Stop Optimizing for Almost
By Cristiano Pierry
Teams that keep waiting for one more polish pass may be optimizing for almost instead of learning from real users.
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 always on time.
My oldest, not so much.
Not wildly late. Not “we need to send a search party” late. More like 5 to 15 minutes late. Consistently. Reliably. Almost professionally.
Dinner? 12 minutes late.
School event? 9 minutes late.
Leaving the house at 3:00? Emerging at 3:11, somehow surprised that time continued moving.
And that consistency reveals the inconvenient truth:
If you are always 5 to 15 minutes late, you probably could be on time.
You have simply optimized for “almost.”
Product teams can do the same thing.
We are not obviously late. We are just waiting for one more feature, one more edge case, one more alignment meeting, one more round of polish, one more “quick” validation before we put something real in front of users.
The delay never feels dramatic. It is just 5 to 15 minutes every day. But those minutes compound.
The market gives better feedback than any conference room. Users will tell you what matters faster than your internal debate will. Reality has a way of cutting through roadmap theater.
Launch the small version. Test the riskiest assumption. Get the signal early. Let the product learn in the wild.
Being punctual in product development does not mean rushing.
It means respecting the learning clock.
Because the team that ships at 3:00 learns at 3:01.
The team that ships at 3:15 is still explaining traffic.
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.