Meta Pay is a payments product used across Meta's ecosystem. Define how you would determine whether Meta Pay is successful, then make a product prioritization decision and debug a metric scenario. ### Constraints & Assumptions - Treat Meta Pay as a platform product with consumer, merchant, creator, nonprofit, and peer-to-peer use cases. - Include both growth and trust/risk metrics; payments volume alone is not enough. - Explain your assumptions before choosing between feature options. - Consider payments reliability, fraud, disputes, compliance, and unit economics. ### Clarifying Questions to Ask - What is Meta Pay's strategic goal this year: consumer habit, commerce conversion, creator monetization, nonprofit giving, or transaction profitability? - Which surfaces are in scope: Facebook, Instagram, WhatsApp, Messenger, Marketplace, or all of them? - Are we optimizing for transaction count, payment value, active users, retention, or margin? - Are there regulatory, region, or funding-rail constraints? ### Part 1 - Define Success For Meta Pay How would you define whether Meta Pay is successful? #### What This Part Should Cover - A north-star metric and a supporting metric tree. - Activation, engagement, retention, reliability, trust and safety, fraud, disputes, and economics. - A distinction between healthy payment volume and unhealthy growth driven by risk, incentives, or poor margins. ### Part 2 - Choose One Feature: Bill Splitting Or Donations If you could build only one feature next year, would you choose a bill-splitting feature or a donations feature? Why? #### What This Part Should Cover - A structured prioritization framework such as RICE or weighted criteria. - Reach, frequency, strategic fit, network effects, trust risk, monetization, and execution complexity. - A clear recommendation with caveats based on company strategy. ### Part 3 - Debug Flat North Star With Lower Cost Per Transaction If your north-star metric stays flat but cost per transaction goes down, how would you debug the situation? #### What This Part Should Cover - Metric validation before interpretation. - Decomposition of the north star into users, frequency, success rate, transaction value, and segment mix. - Decomposition of cost per transaction into funding mix, processor fees, fraud loss, support cost, incentives, and infrastructure. - Possible explanations and next actions depending on whether this is efficiency improvement, growth stagnation, or a hidden quality issue. ### What a Strong Answer Covers - Does not treat one metric as the whole product. - Balances growth, reliability, risk, compliance, and economics. - Makes the prioritization decision conditional on strategy while still taking a clear position. - Debugs with metric trees and segment analysis instead of guessing. ### Follow-up Questions - What guardrail metric would make you stop scaling Meta Pay? - How would your feature choice change if the top goal were trust or brand impact? - How would you detect fraud-driven volume growth? - What would you do if cost improved because high-value users churned? - Which surface would you launch the chosen feature in first?