Product design question

You are a new PM at Google Pay. Design a feature for budgeting.

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Tests product design for a personal finance feature within a payments app, balancing simplicity with genuinely useful budgeting insight.

Clarify scope: a budgeting feature within Google Pay, aggregating spending across linked accounts and cards rather than a full standalone finance app.
Identify the user: someone who uses Google Pay as their primary payment method and wants basic visibility into spending, not a power-user financial planner.
Identify the core job: understand spending by category without manual tracking, and get an early warning before overspending in a category that matters to them.
Propose automatic category tagging of transactions using existing merchant data, a simple monthly budget per category set by the user, and a proactive near-limit notification.
Address the trade-off: budgeting features often fail from feeling too complex or judgmental, so keep the default passive, insights shown not demanded, with opt-in stricter limits.
Define success: budget-setting adoption rate, and reduced overspending in categories where a budget was set versus a control group.

Leverages Google Pay's existing transaction and merchant data for automatic categorization, rather than requiring manual entry.
Proposes a proactive, before-the-fact warning rather than only a retrospective spending summary, directly addressing the budgeting job.
Addresses the well-known failure mode of budgeting apps, feeling like a chore or judgmental, with a passive-by-default design.
Defines success with a genuine behavior-change metric, not just feature engagement.

Proposing a feature that requires heavy manual transaction categorization, ignoring Google Pay's existing automatic data advantage.
Designing an experience that feels punitive or naggy, a well-documented reason budgeting apps see high abandonment.

How would you handle transactions that are hard to auto-categorize accurately?
How would you measure whether the feature actually changes spending behavior versus just being viewed?