Ever waste ten minutes scrolling a food app with no idea what to order?
Friends’ Picks
See what your friends order, and decide faster with recommendations you already trust.
- Role
- Product Manager (concept)
- Research
- 24 interviews
- Behavioural metric
- Time-to-order
- Business outcome
- Order conversion
- Too much choice
- Decision friction
- Trusted recommendation
- Faster decision
- More completed orders
The problem
My role
Hypothesis
What I would watch
Too many choices, too little time
Uber Eats has already solved supply and delivery. What it hasn't solved is the minutes a hungry person spends scrolling before they commit, or the sessions that end with no order at all.
The friction loop
Too many choices
Hundreds of good options, no reason to pick one.
Browsing
Scrolling replaces deciding.
Comparing
Ratings, photos, and delivery times all blur together.
Second-guessing
Every option seems fine, so none feels right.
Longer decision time
Effort climbs while appetite and patience drop.
Potential abandonment
The session ends with no order.
The behavioural metric
Time‑to‑order
The time between opening the app and placing an order. It's the clearest proxy for decision cost. When deciding gets easier, this number drops, and abandonment should drop with it.
Proposed metric
Time-poor decision makers
Not everyone struggles here. The people who do share one trait: deciding costs more than the time they have for it.
Needs
- A decision they can defend in seconds
- Confidence they won't regret the order
- A shortcut that respects their taste
Behaviours
- Open the app already hungry and already late
- Scroll broadly, open a few, compare many
- Fall back on the same handful of safe orders
Frictions
- Undifferentiated ratings from strangers
- Fear of wasting money on an unknown place
- Decision fatigue at the end of a long day
I interviewed 24 people.
Semi-structured 1:1 interviews, focused on how people decide what to eat when they are short on time. Qualitative and directional. No statistical claims are made from this sample.
What I asked: the six areas
How people decide what to eat
Walk me through the last time you ordered delivery. Where did you start, and what made you land on that restaurant?
Decision friction
What makes the choice hard? What are you doing in the minutes before you commit to an order?
Trust
What actually convinces you a restaurant is worth trying? How much weight do ratings and review counts carry?
Friend recommendations
When a friend recommends a place, what do you do with that? Where does the recommendation reach you today?
Abandonment
Have you ever opened a delivery app and closed it without ordering? What was happening at that moment?
Product implications
What would have to be true for a social recommendation surface to be useful rather than noise?
Quotes and findings here come only from the actual interview transcripts. Nothing on this page is attributed to a participant unless they said it.
People don’t need more choice.
They need a reason to choose.
Stranger signal
4.8★
2,400 reviews
Accurate, plentiful, and nearly identical across every option on screen. It weeds out bad restaurants but doesn't pick between good ones.
Trusted signal
“Sarah ordered this.”
“You’d love this.”
Scarce, specific, and personal. It carries taste and context an aggregate score can't, and that's what turns a shortlist into a decision.
Why this complements, not replaces
Uber’s recommendation engine is great at narrowing hundreds of options to a relevant few. It's weaker at the last step: giving someone a reason to commit to one. Trusted recommendations don't replace ranking. They sit on top as a tie-breaker at the moment of decision, and carry a personal signal the engine can't infer from behavior alone.
Uber Eats surfaces trusted friends' recommendations at the moment of decision,
people decide faster and with more confidence,
trusted recommendations cut uncertainty and decision effort.
This is a hypothesis, not a conclusion. The rest of this case study is about how I'd test it, and what it would take to be worth building.
Friends' Picks, end to end
Friends' Picks → friend recommendation → restaurant → checkout → order complete. The prototype is live. Step through the states to see the reasoning behind each interaction.
Friends' Picks in the feed
Why this way
Placed right at the moment of decision, above endless browsing, not buried in a social tab. A separate tab would be a destination nobody visits.
In the prototype
A compact rail of faces and dishes. Recognition first: the person, then the dish, then the restaurant.
Annotations describe intended behavior for a proposed concept, not shipped Uber Eats functionality.
Should Uber build a social graph?
This is the real decision. The feature is easy to sketch and expensive to own. A social graph is a permanent obligation, not a one-time release.
Option A
Full social graph
Upside
- Deep personalization from real relationships
- Network effects that compound with adoption
- A signal competitors can't copy
Cost
- Privacy exposure around what people eat and when
- Cold start: no value until friends show up
- Graph infrastructure and identity resolution
- Added complexity across the whole app
- Permanent maintenance and moderation load
- Notification fatigue that risks core engagement
Option B
Lightweight MVP
Upside
- A fraction of the investment
- Faster validation, weeks not quarters
- Tests the core hypothesis directly
- Almost no privacy surface, since sharing is explicit
Cost
- No network effects, no compounding
- Supply of recommendations stays thin
- Understates the ceiling of the full idea
Recommendation
Start lightweight.
Earn the right to build the social graph.
One share link. No graph.
The smallest thing that can test whether a trusted recommendation changes behavior: let a happy customer hand one to a friend, and see what the friend does with it.
After a good order
“Loved it? Recommend it to a friend.”
Prompt appears once, right after ordering, opt-in only.
The friend receives
“Joshua recommends this restaurant.”
Attribution and dish travel with the link. No account graph needed.
One action
[ ORDER ON UBER EATS ]
Straight into the restaurant, with the recommended dish shown first.
A concept proposal. Not built, not shipped, not an Uber roadmap item.
What I'd measure, and why
Select any step of the funnel to see what it means and what I'd instrument there.
Time-to-order
Does deciding actually get easier?
Order conversion
Does an easier decision turn into an order?
- Orders per user
- Recommended-restaurant orders
- Repeat order rate
- Cancellation rate
- Privacy opt-outs
- Recommendation quality (hide / report)
- Notification fatigue
All metrics on this page are proposed. No Uber internal metric values are shown anywhere in this case study.
How I'd test the hypothesis
A generated dataset of 320 sessions, built to show the analysis approach. It's not from my 24 interviews and it's not Uber data.
Decision time vs completion
Do longer decisions end in fewer orders?
In this sample, completion drops as decision time grows. Directional only: an association, not a cause.
Fatigue vs browsing
Do higher-fatigue users browse more?
Restaurants viewed rises with self-reported fatigue, the browsing cost this feature is meant to cut.
Trust vs receptivity
Are people who trust friends more receptive?
Among exposed users, engagement with a friend recommendation rises with how much they trust friends' taste.
Exposure comparison / generated sample
0.0 min
25.2% completed · 8.3 restaurants viewed
0.0 min
46.9% completed · 7.4 restaurants viewed
In the generated data, exposure lines up with a shorter decision and a slightly higher completion rate. That's an association inside a dataset I built. It shows the analysis, not the effect, and it says nothing about causality.
Which segment looks most promising to test first?
| Segment | Trust | Fatigue | Decision | Δ Completion |
|---|---|---|---|---|
| Parents / caregivers | 3.5 | 3.9 | 8.8 min | +26.5 pts |
| Students | 4.1 | 3.1 | 7.7 min | +24.5 pts |
| Long shift workers | 3.3 | 3.9 | 8.8 min | +21.9 pts |
| Young professionals | 3.9 | 3.6 | 8.3 min | +17.3 pts |
On this generated data, Parents / caregivers would be the first cohort I’d target: the biggest exposure gap in the sample. With real data, this is the same cut I’d run before picking a test population.
How I'd actually find out
A randomized A/B test on the proposed MVP. Designed, not run. No results are claimed.
Control
Current Uber Eats discovery
Existing feed, ranking, and recommendation surfaces. Unchanged.
Treatment
Friends’ Picks
Same feed, plus the trusted-recommendation surface at the moment of decision.
- Incremental completed orders per user
- Time-to-order
- Restaurant → order conversion
- Orders per user
- Repeat order rate
- Cancellation rate
- Privacy opt-outs
- Hide / report rate
- Notification fatigue
- Restaurant concentration
No experiment has been run. No effect sizes, lifts, or significance results are claimed anywhere in this case study.
Would it be worth building?
A framework, not a forecast. Every number here is a placeholder used to show how the decision would be sized.
Value side
- Incremental orders attributable to the treatment
- Contribution margin per incremental order
- Retention effect if trusted discovery becomes a habit
Cost side
- Engineering build and ongoing team cost
- Social graph infrastructure (if pursued)
- Privacy and security review, consent tooling
- Recommendation infrastructure and ranking work
- Long-run maintenance, moderation and support
No Uber financials, margins or order volumes are used or implied.
What I'd do with the result
Committed before the test runs, so the outcome can't be rationalized after the fact.
Scale
Meaningful incremental orders, faster decisions, and healthy guardrails.
Iterate
People engage with the surface, but conversion downstream falls short.
Stop
No meaningful business value, or too much privacy and trust risk.
A feature isn’t a win because people click it.
It’s a win when it creates real value.
What would make me kill this idea?
Friend recommendations don't meaningfully cut decision time versus current discovery.
Order completion rate doesn't move beyond noise in the treatment arm.
Social-graph adoption stays so low that most users never see a trusted recommendation.
Guardrails move the wrong way: smaller baskets or lower satisfaction.
If the recommendation experience doesn't reduce decision time or increase completed orders, the cost and complexity of a social graph isn't justified. That's a decision, not a failure.
Final point of view
The question isn’t whether people would like seeing what their friends recommend.
The question is whether trusted social discovery creates enough value to justify the cost and complexity of building it.
I’d earn the right to build the social graph by first proving that trusted recommendations cut decision friction and increase completed orders.