Fix the leak before you turn up the tap

The strategic question

The digital channel in the group's largest market — native apps and web, ordering food at scale — had an obvious lever: checkout conversion. But conversion work on an ordering platform sits on top of something less visible: whether an order placed actually completes, cleanly, every time. The real question wasn't "how do we lift conversion." It was "what do we need to be true about the platform before conversion work is worth doing at all."

The constraint

Every release cycle carried two competing pulls. One was pressure to ship checkout and funnel improvements fast — new payment options, flow simplification, promotional mechanics — because that's what shows up as conversion in a dashboard. The other was a harder truth: a share of checkout friction wasn't a funnel design problem, it was reliability debt. Orders failing to submit cleanly to a store, edge cases in payment-to-order sync, defects that only appeared at full traffic. Every conversion-focused release risked being undone by the next reliability incident, and customers don't distinguish between "we lost you to bad UX" and "we lost you because the order silently failed."

The decision I owned

I made ordering reliability a precondition for conversion work, not a parallel workstream competing for the same slots. Concretely, that meant declining to greenlight several funnel experiments until the underlying failure modes they'd inherit were addressed — delaying visible funnel improvements while we fixed failures in the order journey itself, a trade-off that read as slow to anyone measuring velocity by shipped features rather than by orders that actually complete.

The second piece was operational readiness — with the release mechanism scaled to the blast radius of the change. For the platform replacement itself, the highest-impact change a channel can absorb, I ran three-plus beta phases, each reaching a limited, representative slice of stores and users so defects surfaced while the damage was still contained, rather than at 100% traffic. For ongoing iteration, the discipline is lighter but constant: phased rollouts through blue-green and canary deployments, holding each change at partial traffic until stability and reliability signals confirm the platform is steady, then completing the rollout.

And when the question isn't "is it stable" but "does it actually help," I reach for A/B testing before committing a change publicly. One example: whether a cross-sell popup after a user adds an item to cart would hurt checkout conversion more than the attach rate it gained. I ran it as an A/B test on real traffic, measured both variants against each other, and shipped the one that performed better once the test closed — rather than settling it by argument in a room. That's the mechanism that let conversion work compound instead of periodically resetting to zero.

The outcome

Six months after the new platform fully replaced the legacy stack in the Philippines, compared with the same period the year before: sales were up 12%, transactions up 13%, and checkout conversion reached 21% of all engaged sessions — up from roughly 14% on the legacy platform, and well above the ~4.2% industry benchmark for F&B ordering platforms in the Philippines.

Those numbers followed the platform replacement. I can't cleanly separate how much of the lift came from reliability specifically versus the funnel work that shipped on top of it — what I can point to is the sequencing: reliability first, so conversion work compounded on a platform that held under load instead of resetting with every incident.

Just as important, the beta-program discipline meant defects were identified and resolved during the phased rollout, so full launches inherited fewer unresolved issues — reducing, though not eliminating, the regression risk releases carried into the metrics above.

What I'd tell another product leader

Don't let conversion work get credit or blame for problems that are actually reliability problems wearing a funnel costume.

If you can't trust that what you shipped last release is still standing, every new experiment is just adding variance, not signal. Fix the leak before you turn up the tap — and build the release process that lets you find leaks before your customers do.