Priority Delivery

Priority Delivery offered diners a faster delivery option for an additional fee. View press release →

The Challenge

Grubhub wanted to offer a premium delivery option: faster ETAs for an additional fee. Research showed 25% of diners indicated interest in faster delivery, and prior experiments had demonstrated that lower ETAs correlate with higher conversion.

The feature sounded simple: show a faster ETA, charge a fee. But delivery networks have complex dynamics.

Why This Was Hard

The core tension: Every delivery we make faster potentially makes other deliveries worse or more expensive. The question wasn't just "can we offer priority delivery?" but "can we do it without breaking the marketplace?"

The Approach

Two Questions to Answer

I owned the logistics side of Priority Delivery — validating whether we could actually deliver faster without breaking the network, and whether the economics would work. Before building anything, I needed to validate:

1. Is Priority Delivery logistically feasible? Can we actually make deliveries ~5 minutes faster without degrading the network?

2. Is Priority Delivery financially viable? Will revenue from the feature offset any increase in fulfillment costs?

Success required tight partnership. The diner PM's pricing results directly informed my exposure decisions — higher adoption at lower price points meant more strain on the network, which meant I might need to reduce exposure % to stay within lateness guardrails.

Experiment Strategy: Isolate, Then Combine

Rather than testing everything at once, I designed a series of experiments that isolated individual variables before combining them:

Experiment 1 — Exposure %: How many orders can we prioritize before the network degrades? I tested various exposure thresholds, measuring the impact on late % and fulfillment cost at each level.

Experiment 2 — ETA Speedup: How much faster can we promise? I tested 2, 5, and 10 minute speedups against our lateness and cost guardrails.

Experiment 3 — Dispatch Prioritization (Isolated): Before combining dispatch prioritization with shorter ETAs, I tested the prioritization mechanism alone. This let me understand the isolated effect of having dispatch favor certain orders — separate from the effect of showing users a shorter ETA. This was critical for understanding which lever was driving which outcome.

Combined Experiment: After understanding each lever in isolation, I combined them to test interaction effects and find the optimal configuration.

Metrics Framework

• Priority Delivery late % (target: < 10%)
• Standard Delivery late % (target: < 20%)
• Revenue from Priority Delivery fees

• Total fulfillment cost
• Average ETA
• Driver pay per delivery
• Care contacts per order
• Courier engaged minutes
• Bundle %

Key Finding

We could prioritize approximately 20% of deliveries with a ~5 minute speedup while maintaining acceptable performance on all guardrail metrics.

Implementation

Backend Requirements

I wrote functional and technical requirements for how dispatch would handle priority orders:

• How does dispatch "prioritize" a delivery? What intervention does it make?
• How is an order marked as "priority" so dispatch can target it?
• How do we ensure prioritization actually results in faster delivery?
• How do we prevent priority orders from degrading standard orders beyond acceptable thresholds?

Pricing Coordination

The diner PM ran A/B/n pricing tests. I tracked results closely because adoption at different price points directly affected my exposure decisions:

• Higher adoption (at lower prices) → more priority orders → more strain on network
• More strain → either accept worse lateness metrics OR reduce exposure %
• This created a direct link between pricing strategy and logistics constraints

We initially offered Priority Delivery free for GH+ subscribers to drive subscription value. Several months later, the business moved to a discounted model for subscribers.

GTM Strategy

We optimized for low risk:

1. Dogfooded with employees first
2. Exposed a very small % of markets and diners initially
3. Gradually ramped up exposure while monitoring guardrails
4. Pre-determined experiment duration based on power analysis

Results

The 46% adoption validated strong product-market fit — nearly half of diners who saw the option chose to pay for faster delivery.

What I Learned

Marketplace Equilibrium

You can't optimize one part of a delivery network in isolation. Every change has ripple effects:

• Faster deliveries for some → less slack for bundling
• Less bundling → higher fulfillment cost
• Higher fulfillment cost → need higher prices → lower adoption

The PM's job is to find the equilibrium that creates value for users AND the business. This requires understanding how all the pieces connect, not just optimizing your own domain.

Isolate Variables Before Combining

Testing the dispatch prioritization mechanism in isolation — before combining it with shorter ETAs — was critical. It let me understand which lever was driving which outcome, rather than seeing a combined effect I couldn't decompose.

This is especially important for features with network effects, where multiple variables interact in non-obvious ways.

Cross-functional Partnership on Constraints

The logistics constraints and pricing strategy were tightly coupled. Higher adoption at lower prices meant more network strain. I couldn't set exposure limits without knowing expected adoption; the diner PM couldn't finalize pricing without knowing what the network could handle.

This required genuine partnership, not just handoffs. We had to iterate together, with each side's learnings informing the other's decisions.