Designing a credit card bill-pay experience inside Google Pay

You have just joined Google Pay as a product manager, and you are asked to design a feature that helps people pay their credit card bills. Explain what the feature should achieve for users and for Google, who it is for, what you would build first and why, and how you would judge whether it succeeded. ```hint Follow one billing cycle Walk through what a cardholder does today between a statement closing and the payment posting, and note every place where the work is split across different apps, websites, logins and reminders. ``` ### Clarifying Questions - Which cards should the feature cover: any card a user already stores in Google Pay, cards from any issuer, or only a Google-affiliated card? - Should Google Pay move the money itself from a linked bank account, or hand the user off to the card issuer to finish the payment? - Which country is the launch for, given that payment and financial-data rules differ by market? - Is the priority bringing new people into Google Pay, getting existing users to use it more often, or something else? ### What a Strong Answer Covers - A stated goal for the feature and how it ties back to Google Pay's and Google's interests - Cardholder segments compared, with one chosen and the reason for the choice - Bill-payment pain points ranked by severity, mapped to features, and cut down to a first release - The dependency on card issuers and banks for balances, due dates and payment rails, and how it shapes the plan - A success metric with guardrails, plus the risks of handling people's money and how to contain them ### Follow-up Questions - Why would a card issuer share balance and due-date data with Google Pay, and what would you offer in return? - A scheduled payment fails and the user is charged a late fee. What should the product do, and who should bear the cost? - How would the design change for someone who carries a balance and cannot pay every card in full each month?