Designing products and services based on Jobs to be Done

Summary

The Jobs to be Done (JTBD) framework helps organizations understand consumer goals by defining a job as the progress a consumer seeks to achieve in a specific context. To prioritize new features, GrabFood applied this framework and force diagrams to investigate consumer motivations and friction points. Interviews revealed that working parents ordering family meals experienced anxiety from navigating excessive individual choices during checkout. To address this obstacle, Grab developed an algorithm within the GrabMerchant application that identified complementary food items and automatically suggested ready-made bundles. Following the release, thousands of merchants adopted one-tap bundle creation, streamlining ordering for families while supporting restaurant growth.

Context

A team at GrabFood needed to prioritize features and products to build, but lacked a fundamental understanding of why consumers were using GrabFood or other food delivery services.

Approach / What changed

Grab applied the Jobs to be Done (JTBD) framework and force diagrams to conduct customer interviews, identifying checkout anxiety among working parents, and subsequently built an algorithm in the GrabMerchant app that automatically matches complementary items to suggest instant bundles to merchants.

Takeaways

• A single product can fulfill multiple Jobs to be Done depending on context, such as milkshakes serving as filling morning commute snacks or afternoon treats for children.
• GrabFood used force diagrams to analyze consumer decisions across four dimensions: current jobs, prior solutions, push/pull triggers, and inertia or anxieties.
• GrabMerchant integrated an algorithm that identifies complementary menu items and suggests one-tap bundles, which thousands of restaurants adopted to reduce customer checkout friction.

Related reading

• Grab · Jul 19, 2021

  Processing ETL tasks with Ratchet

  Grab's Lending team relies on multiple microservices to finance various user segments, requiring automated pipelines for operational tasks like loan rescheduling and merchant whitelisting. To execute these workflows, the team uses Ratchet, a Go library that organizes data pipelines into concurrent stages connected by Go channels and JSON payloads. In the Azkaban service, each ETL task is structured as a Job Processor that configures custom Data Processors for extraction, transformation, and loading. For merchant whitelisting, a custom processor pulls uploaded CSV files from Amazon S3, validates the rows to prevent manual errors, calls microservice APIs, and passes the output to an empty load stage. This pipeline architecture allows the team to isolate failures quickly, eliminate manual data validation, and automate routine operational tasks.

  Amar Prakash

• Grab · Oct 30, 2020

  Keeping 170 Libraries Up to Date on a Large Scale Android App

  Grab's passenger Android superapp relies on more than 170 in-house and open-source libraries, incorporating five to ten library bumps into each weekly release. Although developers often avoided updates due to the fear of leaking defects or crashes into production, the engineering team established a risk-assessment framework based on codebase usage and the volume of incoming changes. To minimize update diffs and avoid accumulating large issues, libraries are updated incrementally on a weekly cadence matching upstream release schedules. Automated UI test cases written in Gherkin syntax execute on CI for every merge request, while high-risk bumps trigger targeted QA manual testing. This structured updating process prevents defect leakage while keeping the application compliant with evolving Google Play target API requirements.

  Lucas Nelaupe

• Grab · Dec 22, 2020

  Pharos - Searching Nearby Drivers on Road Network at Scale

  Ride-hailing allocation requires identifying nearby drivers based on actual routing distance and estimated time of arrival rather than straight-line haversine distance. Grab developed Pharos, a distributed in-memory spatial microservice that evaluates road networks to match fast-moving drivers with pick-up requests. The system partitions OpenStreetMap road graphs by city and vehicle vertical while indexing driver positions and edge-based nodes using Adaptive Radix Trees. To locate candidates, Pharos projects driver coordinates onto road segments as phantom nodes and runs Incremental Network Expansion to compute isochrone reaches. Read-write concurrency is managed by switching tree root snapshots, allowing concurrent reads while updates produce new roots for subsequent lookups.

  Hao Wu

• Grab · Nov 22, 2021

  Using real-world patterns to improve matching in theory and practice

  Continuous ride-hailing assignment relies on solving the minimum weight bipartite matching problem between passengers and driver-partners. While traditional implementations assume a precalculated cost matrix, computing shortest-path travel times across large road networks dominates total execution time. Researchers introduced an Incremental Kuhn-Munkres algorithm that leverages the spatial locality of optimal matches to compute edge costs on demand. The approach integrates priority queues and lower-bounding techniques with refinement rules to avoid evaluating distant pairs while guaranteeing the same optimal assignment. Evaluated on Singapore road network data and real Grab production workloads, the incremental techniques reduced exact cost calculations and decreased assignment running times by over an order of magnitude.

  Tenindra Abeywickrama