How does Grab build products for a diverse region?

Samir Kumar, Head of Mobility

. August 1, 2024 . Regional

Building scalable digital products for Southeast Asia is a complex task—each market varies greatly in needs, problems, and local tastes.

Grab’s product teams constantly ask themselves: should our solutions be tailored for each market or should they cater more broadly to the region?

The truth is, we apply both approaches.

Earlier this year, for example, Advance Booking, which lets Grab users schedule rides instead of ordering on-demand, received an update. This is an example of a regional feature that was rolled out to many Southeast Asian cities at once.

Meanwhile, in the Philippines, we’ve done something completely unique and local, which is to build MOVE IT, an on-demand motorcycle taxi app, to meet the specific mobility needs there.

There is no hard and fast rule when it comes to finding a balance between localising a product or going regional with it.

Think regional for scale

We have, however, learned a thing or two that have helped us serve the diverse region effectively.

When we lean into building products on a regional level, it is because it allows us to solve problems at scale. This accelerates our ability to experiment and enter markets quickly. It enables us to run tests on a broader scale instead of scattered experiments in individual markets.

A product or feature that is available regionally also leads to a predictable and smooth user experience.

For instance, Grab users in Singapore should not see a completely different user interface when they’re in Bali. Offering a consistent user experience across the region allows us to measure success uniformly throughout the region.

Building products at a regional level is more cost-effective too. Developing technology is an expensive and labour-intensive process—fragmentation of tech may incur higher costs and put a dent on investment returns.

Tailor where it counts

Still, we recognise the importance of localisation under some circumstances.

We assess whether we should localise a product or service based on some of these considerations: Does the impact we can create justify the effort required? Is localisation needed in order for us to adhere to local regulations? Is the issue that we are solving unique?

When we make such exceptions, we make them count.

In Jakarta, for instance, we developed a solution to overcome the concerns driver-partners had with the city’s odd-even car licence plate traffic regulation.

The regulation requires private cars to take turns accessing particular roads in the city based on whether their car plates end with an odd or even number. So we built an algorithm to ensure that job assignments would adhere to the traffic regulations.

Local AND regional

Lastly, there are also occasions where products are regional and localised at the same time.

For example, we use artificial intelligence (AI) extensively to prevent fraud on Grab. We have over 1,000 AI models in production—one of the highest in the region.

The AI models used for fraud prevention are typically built regionally. But methods employed by malicious actors to bypass our systems may vary across each market. This is when country teams have to tailor these models based on local regulations, needs and data.

In summary, there are many benefits to building products that suit multiple markets. But we stay open to opportunities that may arise from catering to unique market needs, and tailor products when necessary.

At the heart of it, our goal is to meet the diverse needs of Southeast Asia in the most efficient and effective way.

Design and research

How does Grab build products for a diverse region?

Think regional for scale

Tailor where it counts

Local AND regional

Komsan Chiyadis

Komsan Chiyadis