Two different companies. Two different industries. Two moments where the technical constraints made the work feel impossible. Two outcomes I am still proud of years later.
The first was a telemedicine startup.
We were operating a telemedicine platform in which each clinical environment had its own color requirements. Accessibility standards, brand specifications, state-level compliance variations. The design team was managing color deployments manually across a growing number of environments. The process took roughly 160 hours with a five-person team. It was unsustainable, and everyone knew it.
The answer was a pipeline we called Color Math — an automated deployment system that reduced 160 hours of manual effort to roughly 2 hours with a single technical PM. The operational cost reduction was in the millions of dollars.
The thing that almost stopped it from existing was the near-universal belief early on that automating color at that level of complexity across that many environments was not technically feasible.
It was feasible. It just required someone willing to hold the vision long enough, and to collaborate with an incredible engineer to solve the HSL color math at the core of it.
The second was an EDI startup.
EDI onboarding is one of the most technically complex and user-hostile processes in enterprise software. Trading partner onboarding that took 90 days was considered normal. We got it to 9 days. That was the number we talked about publicly, and it was real.
What we did not talk about as much was WebEDI. A product that took the onboarding experience and reduced it further — from days to hours, and in the right conditions, from hours to minutes. For an industry where onboarding timelines are measured in quarters, that outcome was not incremental. It was a rethinking of what the process could be when someone designed it for the human doing it, rather than for the system processing it.
Both of those outcomes started in the same place. Someone said it could not be done. The technical constraints were real. The skepticism was reasonable. The window was closing, and the pressure was high.
What made them possible was the decision to treat the constraint as a design problem instead of a hard stop.
To ask what would have to be true for this to work, instead of accepting the list of reasons it would not.
That is the work I am most proud of. Not because the numbers are good, though they are. Because in both cases, the work required holding a position that felt unreasonable until it did not. Because the outcome required trust — built over months — to survive the moments when the answer was still no.
Work that almost did not ship. Work that mattered because it did.