Influence Stakeholders for Product Decision at Meta

Below is a teaching-oriented approach and a model answer tailored for a Data Scientist in a cross-functional, high-scale environment like Meta. ## How to Structure Your Answer (STAR+E) 1) Situation: Product context, users, baseline metrics, constraints. 2) Task: The decision to be made and what was at stake. 3) Action: Your influence methods (analysis, experiments, stakeholder alignment, decision frameworks). 4) Result: Quantified impact, including primary and guardrail metrics. 5) Extension: Reflection/learning and how you institutionalized the change. Tip: Map stakeholders explicitly. Examples: PM (outcome owner), Eng Lead (feasibility/latency), Infra (cost), Integrity/Privacy (risk), Design/UX (experience), Legal/Policy (compliance), DS/DE (data/experimentation), UXR (qual insights). ## Communicating Trade-offs - Frame the decision: "We’re choosing between A and B to move metric M under constraints C." - Use an impact vs. cost/risk table. Include: - Projected lift (e.g., +1.5% DAU) and confidence bounds. - Infra cost/latency (e.g., +8 ms at P95), complexity. - Integrity/privacy risk (e.g., increase in complaint rate?). - Time-to-ship and operational burden. - Guardrails: Define thresholds you will not cross (e.g., complaints, latency SLA, fairness metrics). Simple sizing example: - If baseline daily notifications sent = 500M and option B reduces low-value sends by 12% with neutral engagement, infra cost savings ≈ 60M sends/day. - A/B sample size (rough): n per variant ≈ 2 * (Zα/2 + Zβ)^2 * σ^2 / δ^2. For proportions, plug σ ≈ p(1−p). This keeps your impact claims credible. ## Alignment and Execution Tactics - Pre-align via 1:1s to surface concerns and tune the decision doc. - Use DACI/RACI: name the Approver (often PM), Driver (you/PM), Contributors (Eng/Integrity/Infra), Informed (Leadership/Support). - Decision doc with pre-read > live meeting for decision and next steps. - Convert decision to an execution plan: owners, milestones, experiment design, rollout/ramp, monitoring dashboards, and rollback criteria. ## Model Answer (2–3 minutes) Situation: Our messaging team saw a rise in notification hides/complaints, and new-user 7-day retention was flat. We suspected low-value notifications were eroding trust. We needed to decide between investing in a complex ML precision upgrade or introducing a lightweight frequency cap targeting low-value alerts. Task: Influence PM, Eng, Infra, and Integrity to choose an approach that improved retention while protecting trust, privacy, and latency SLAs. Action: - I built an offline analysis tagging notifications by predicted value and found the bottom 30% of sends accounted for 70% of hides/complaints. I simulated two options: (A) ML precision upgrade; (B) value-aware frequency caps that suppress low-value sends. - I estimated impact: Option B projected −12% send volume, −18–25% complaints, with neutral-to-slightly-positive session starts; infra savings were material. Option A projected similar complaint reduction but needed 2–3 sprints and added ~8–12 ms P95 latency. - I created a one-page decision doc with trade-offs (impact, engineering time, latency, privacy/integrity risk) and defined guardrails: complaints −10% minimum, latency +5 ms max, no adverse effects on sensitive cohorts. - I pre-aligned in 1:1s: Integrity wanted strict guardrails; Infra favored B for cost; Eng flagged A’s complexity; PM prioritized speed to impact. In the decision meeting, using DACI, we agreed to test Option B first, with a follow-on path to A if results were inconclusive. - I led the experiment design: power analysis for 0.3 pp complaint-rate reduction, 2-week A/B with holdouts, cohort-level fairness checks, and real-time dashboards with rollback criteria. Result: - Option B reduced notification hides/complaints by 22% (p<0.01), improved new-user 7-day retention by 1.6%, and cut sends by 15%, decreasing infra workload. DAU remained neutral; P95 latency change was +2 ms, within SLA. No adverse effects in sensitive cohorts. - We rolled out globally over 3 weeks with staged ramps and added a periodic re-tuning job. I documented the approach as a reusable playbook for other surfaces that send notifications. Extension: I learned to separate “consent vs. consensus” and to anchor trade-offs in metrics and guardrails. The decision doc + pre-alignment compressed decision time and increased trust. ## Pitfalls to Avoid - Vague impact claims without baselines, CIs, or power analysis. - Ignoring guardrails (complaints, latency, integrity/privacy) or sensitive cohorts. - Letting the meeting be the first time stakeholders see trade-offs (do pre-reads/1:1s). - Confusing consensus with progress: define the Approver and decision date. ## Reusable Template (Fill-In) - Situation: "We observed [problem/metric] in [product/surface]." - Task: "We needed to choose between [Option A] and [Option B] to move [metric] under [constraints]." - Action: - "I analyzed [data/method], projected [impact] with [assumptions], and mapped trade-offs (impact, cost, latency, risk)." - "I pre-aligned with [stakeholders], created a decision doc, and used [DACI/RACI]." - "I led experiment design with [primary metric], guardrails [X, Y], and [power analysis/ramp plan]." - Result: "Outcome was [quantified impact]. Guardrails were [met/violated]. We [rolled back/rolled out] and [institutionalized learning]." - Reflection: "What I learned and how I applied it later." ## Likely Follow-Ups (Prepare Brief Answers) - How did you handle a stakeholder who disagreed? - What assumptions were most fragile, and how did you de-risk them? - How did you measure long-term effects vs. short-term lift? - What would you do differently next time? This approach demonstrates communication, leadership, collaboration, and measurable impact while showing strong data rigor and stakeholder influence.