Checkout conversion on a platform serving the group's largest market

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 — a call that was unpopular with 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: we wanted to introduce a cross-sell popup after a user adds an item to cart — the open question being whether the interruption would hurt checkout conversion more than the attach rate gained. That's not a debate to settle in a meeting room; it's a test you run on real traffic before the change earns a full rollout. None of this was a compliance checkbox; it was 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: sales were up 12%, transactions up 13%, and checkout conversion reached 21% of engaged sessions. Those numbers held because they were built on the reliability work, not in spite of it.

Just as important, the beta-program discipline meant full rollouts arrived with fewer defects already known and fixed, so releases stopped being a source of regression risk for the metrics the business actually cared about.

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.