Google Maps: Meet Halfway Mode

Maps has spent its product life optimizing one-to-one directions, but a rising share of Maps sessions start from a group plan being negotiated over a separate chat app. The coordination moment, which is the hardest part of getting three friends to meet, lives outside the product that should own it.

Places data is now cheap and fast enough that a real-time, multi-user venue ranker can run inside the map surface without a dedicated backend. The feature is cheap to prototype and cheap to ship, which was not true a few product cycles earlier.

Classical "meet in the middle" tools fail on two dimensions at once. They support only two users, and they return a geometric centroid that routinely lands in an ocean, on a freeway, or on a residential block with no venues. The user is still the one doing the real work.

For a maps product, this is a coordination tax that keeps users inside chat apps when they should be inside the map. Moving that decision into the map surface increases the value of each session and raises the probability of a downstream navigation.

The bet is that fairness, not the midpoint, is what users actually want. A meetup feels successful when nobody believes they traveled too far. It does not feel successful just because everyone traveled the same amount.

The scoring formula makes this explicit. The score for each venue equals (MaxCommute times 0.7) plus (Variance times 0.3). Seventy percent of the score protects the person with the longest trip. Thirty percent keeps travel times close to each other. A lower score is better.

Party Mode supports any number of users, not only two. Each user drops a pin on the map. The engine computes the centroid of those pins, then uses the Google Places API to fetch real venues within a four-kilometer radius of that centroid. This step solves the "meet in the ocean" failure mode because the candidate list is always a real business on land.

Travel times are estimated using the Haversine formula combined with a small random multiplier between 0.9 and 1.3 on a thirty kilometers per hour urban base speed. This keeps API cost at zero while still producing travel time vectors that rank venues sensibly.

The prototype ships real cost assurance: a cap of one hundred searches per day, a graceful fallback to simulation mode if the API takes longer than five seconds, and a hard-coded kill switch to prevent accidental spend after the trial window.

I used a simulated travel time model rather than the Distance Matrix API. The decision was about cost, not accuracy. A production version would use Distance Matrix for the top three candidates only, and keep the simulation for the long tail.

I did not build account state. All preferences are passed in as ephemeral pins. For a prototype this is the right choice, because forcing a login would have killed the core insight the prototype is trying to validate.

The scoring formula is not shown to users in this version. The code makes it visible to a PM reviewer, but the surfaced output is just the ranked list. A future version should show why each venue was picked, because that is the difference between a list and a conversation.

The value of this feature is measured in downstream navigations per group session, not in clicks. A group plan that concludes inside Maps produces several routes, one per person, rather than the single route a solo session produces.

The fairness engine is a defensible product surface. The weighting can be adjusted for local norms, such as weighting variance higher in regions where equal treatment matters more culturally, and that localization work is difficult for a competitor to match without significant PM investment.