Test Whether Group Diners Need a Dedicated Bill-Splitting App

Quick Overview

A product validation prompt about an app that divides restaurant and bar bills among the people at the table. It tests breaking a product idea into testable assumptions, weighing current workarounds, gathering cheap evidence through interviews, surveys, demand tests and prototypes, and setting go or no-go thresholds in advance.

Test Whether Group Diners Need a Dedicated Bill-Splitting App

Company: Google

Role: Product Manager

Category: Analytics & Experimentation

Difficulty: medium

Interview Round: Other

When a group of friends, family or colleagues eats or drinks out together, someone has to work out who owes what once the bill arrives. You are considering an app that splits restaurant and bar bills among the people at the table. Before anything is built, explain how you would validate whether people truly need it: what would have to be true, how you would collect evidence, and which results would lead you to build it, reshape it or drop the idea. ```hint Separate the problem from the product Showing that splitting a bill is irritating is not the same as showing people will open a new app for it. Break the need into separate assumptions that must all hold, and test the riskiest one in the cheapest way first. ``` ### Clarifying Questions - Are we a new startup, or an established company that could offer this inside a payments or wallet product it already runs? - Does the app only work out each person's share, or does it also collect and send the money between people? - Which country or market are we validating in, and do we have any existing user or transaction data to draw on? - How much time and budget do we have before a build decision is due? ### What a Strong Answer Covers - The need broken into explicit, testable assumptions: how often groups split bills, how painful it is, how well current workarounds serve them, and whether the whole group would go along with a new app. - An honest look at today's alternatives, from splitting the check across cards at the table to one person paying and collecting through a payment app. - Evidence gathered from cheapest to most expensive: existing data, interviews, a survey, demand tests and a minimal prototype. - Success metrics and go or no-go thresholds set before the tests, emphasizing repeat use and spread through groups over sign-ups. - Other product shapes to consider if a standalone app is not justified, plus risks such as payments regulation and disputes over amounts. ### Follow-up Questions - Your survey shows most people find splitting bills annoying, but repeat use of your prototype is low after a month. What do you conclude, and what do you do next? - How would your plan change if you already ran a large peer-to-peer payments app? - If more restaurants let each diner pay their own share at the table, does that strengthen or weaken the case for your app?

Overview: A product validation prompt about an app that divides restaurant and bar bills among the people at the table. It tests breaking a product idea into testable assumptions, weighing current workarounds, gathering cheap evidence through interviews, surveys, demand tests and prototypes, and setting go or no-go thresholds in advance.

Google logo
Google
Apr 25, 2025
mediumProduct ManagerOtherAnalytics & Experimentation
0
0

When a group of friends, family or colleagues eats or drinks out together, someone has to work out who owes what once the bill arrives. You are considering an app that splits restaurant and bar bills among the people at the table. Before anything is built, explain how you would validate whether people truly need it: what would have to be true, how you would collect evidence, and which results would lead you to build it, reshape it or drop the idea.

Clarifying Questions Guidance

  • Are we a new startup, or an established company that could offer this inside a payments or wallet product it already runs?
  • Does the app only work out each person's share, or does it also collect and send the money between people?
  • Which country or market are we validating in, and do we have any existing user or transaction data to draw on?
  • How much time and budget do we have before a build decision is due?

What a Strong Answer Covers Guidance

  • The need broken into explicit, testable assumptions: how often groups split bills, how painful it is, how well current workarounds serve them, and whether the whole group would go along with a new app.
  • An honest look at today's alternatives, from splitting the check across cards at the table to one person paying and collecting through a payment app.
  • Evidence gathered from cheapest to most expensive: existing data, interviews, a survey, demand tests and a minimal prototype.
  • Success metrics and go or no-go thresholds set before the tests, emphasizing repeat use and spread through groups over sign-ups.
  • Other product shapes to consider if a standalone app is not justified, plus risks such as payments regulation and disputes over amounts.

Follow-up Questions Guidance

  • Your survey shows most people find splitting bills annoying, but repeat use of your prototype is low after a month. What do you conclude, and what do you do next?
  • How would your plan change if you already ran a large peer-to-peer payments app?
  • If more restaurants let each diner pay their own share at the table, does that strengthen or weaken the case for your app?