Use these prompts to demonstrate four PM capabilities: analytical decision-making, mobile execution, international product judgment, and experimentation discipline. Keep each story specific enough that the interviewer can ask follow-ups. ## 1. Experience using analytical tools Strong answer structure: - Situation: A product metric changed or a decision needed evidence. - Task: You owned the analysis or decision recommendation. - Action: You used tools such as SQL, Amplitude, Mixpanel, Looker, Tableau, notebooks, logs, or experiment dashboards to diagnose the issue. - Result: The analysis changed prioritization, launch scope, or product design. Example: "In one onboarding project, activation dropped after a redesign. I used funnel analytics to isolate the drop-off step, SQL to segment by platform and acquisition channel, and dashboard data to monitor the trend over time. The key finding was that Android users on lower-end devices were abandoning during a permissions step at a much higher rate. I partnered with engineering to validate that the step had a performance issue, then worked with design to simplify the flow and reduce load time. The decision changed from adding more education to fixing the performance and error-recovery problem first. The result was a measurable recovery in onboarding completion." Why it works: the tools serve the decision; they are not just a list. ## 2. Optimizing a mobile platform feature Strong answer structure: - Situation: A mobile feature had low engagement, poor conversion, high friction, or quality issues. - Task: Improve the outcome within mobile constraints. - Action: Combine user research, analytics, design iteration, release planning, and measurement. - Result: Name the metric improved and any guardrails monitored. Example: "I owned a saved-items feature in a mobile app. Users saved content but rarely returned to it. Research showed that the feature solved a real need, but the entry point was buried and users forgot what they saved. I prioritized a lightweight optimization rather than a full redesign: improved entry-point visibility, better organization, and reminder notifications with frequency caps. I worked with design on the surface area tradeoff and with engineering on release sequencing. We tracked revisit rate, notification opt-outs, and downstream retention. The feature became more useful without creating notification fatigue." ## 3. Localizing a feature across countries A strong localization answer shows that you know the difference between translation and product adaptation. Example: "When expanding a payments-related feature into multiple countries, I started by separating the global core from local requirements. The global core was the same user goal, risk model, and success metrics. The local layer included language, payment methods, identity fields, legal copy, support expectations, and market-specific trust signals. I worked with local operations, legal, research, design, and engineering to identify which differences were must-haves versus nice-to-haves. Instead of building separate products for each market, we created configurable components where local variation was expected. We rolled out market by market, monitored conversion and support contacts, and documented a localization playbook for future launches." Tradeoffs to mention: - Global consistency versus local relevance. - Speed versus compliance or support readiness. - Configurability versus engineering complexity. ## 4. Experiment you ran Strong answer structure: - Hypothesis: what behavior you expected to change and why. - Design: randomization, eligibility, duration, and exposure. - Metrics: primary metric, secondary diagnostics, and guardrails. - Decision: ship, iterate, rollback, or segment. Example: "We hypothesized that simplifying a trial signup flow would increase conversion. I defined trial-start conversion as the primary metric and paid conversion, support contacts, and fraud signals as guardrails. We randomized eligible new users at the account level and pre-committed to a minimum sample size before reading results. The experiment increased trial starts, but the downstream paid conversion lift was smaller than expected and one segment showed worse quality. Instead of shipping broadly, we launched the simplified flow for lower-risk users and kept the additional verification for the higher-risk segment. The main learning was that a top-of-funnel win is not enough if downstream quality or trust metrics regress." ## How to tailor this to OpenAI Do not force AI-specific claims if your background is not in AI. Instead, emphasize transferable PM traits: - Building products where user trust and comprehension matter. - Measuring both engagement and quality. - Iterating with cross-functional teams. - Localizing complex products responsibly. - Running experiments without over-optimizing a shallow metric. ## Common pitfalls - Listing tools without explaining the decision they influenced. - Describing mobile feature work without a user problem. - Treating localization as translation only. - Calling something an experiment when it had no hypothesis, guardrails, or decision rule. - Inventing metrics or overstating ownership.