Convince Stakeholders: Prioritize Data Science Projects Effectively

# How to Answer: Structure and Model Responses ## Part A — Influencing Non-Technical Partners (Use STAR) 1) Situation - Briefly set the business context and the user/merchant/courier impact. - Example context: On-demand marketplace facing late/variable deliveries and high cancellations. 2) Task - Your objective and why it mattered (tie to a clear KPI: on-time rate, cancellations, courier idle time, contribution margin, NPS). 3) Action - Stakeholder mapping: Identify who is affected and who decides (e.g., Ops leads, PM, Eng manager, Merchant partner team). Anticipate incentives and objections. - Evidence-building: Exploratory analysis to quantify the problem; baseline metrics; relevant benchmarks. - Translate to business terms: What metric moves, by how much, and why it matters financially or operationally. - Risk reduction: Propose a low-risk pilot or A/B test; define guardrails and success criteria. - Communication: Simple visuals (before/after funnel, time-series), crisp narrative, FAQs for likely concerns; avoid jargon. 4) Result - Report outcomes with numbers and adoption details. Include follow-ups (rollout plan, monitoring, learnings). Example STAR story (condensed) - Situation: Couriers spent excessive time waiting at pickup, causing delayed deliveries and higher cancellations in several metros. - Task: Reduce courier wait and improve on-time delivery without hurting order acceptance. - Action: Mapped stakeholders (Ops worried about restaurant readiness; PM about delivery ETA accuracy; Eng about complexity). Ran analysis showing 18% of orders had >6 min pickup wait. Proposed dynamic prep-time prediction and slightly later courier dispatch for long-prep orders. Framed impact in business terms and proposed a 2-week A/B in two cities with guardrails (no >1% increase in unassigned orders). Built a simple dashboard to share daily results with non-technical partners. - Result: Pilot reduced average courier idle time by 12%, improved on-time rate by 3.4 pp, and lowered cancellations by 1.1 pp with no impact on order acceptance. Partners approved phased rollout; we added alerting to catch any city regressions. Why this works - Starts with the problem and KPI, not the model. - Minimizes risk via a pilot and guardrails. - Uses clear, visual storytelling and stakeholder-aligned benefits. Pitfalls to avoid - Jargon-first explanations; proposing a model without a business KPI. - Skipping a pilot when stakeholders are risk-averse. - Ignoring operational lift or edge cases (e.g., small merchants with variable prep times). ## Part B — Prioritizing Competing Requests Core principles - Align to company and team goals (e.g., on-time rate, cancellations, LTV, margin). If an item doesn’t map to a goal, de-prioritize or clarify the problem. - Use a transparent scoring framework and share the decision log. - Balance short-term wins with platform/infra investments. Step-by-step framework 1) Intake and clarify - For each request: problem statement, target metric, expected user/ops impact, urgency, constraints, and dependencies. 2) Estimate impact, effort, and confidence - Impact: projected change in a KPI (use ranges: High/Medium/Low or 1.0/0.6/0.3). - Effort: team-weeks including data/eng/QA/experimentation time. - Confidence: evidence quality (historical data, prior experiments, uncertainty). 3) Score with RICE (or ICE) - RICE = (Reach × Impact × Confidence) / Effort - Reach: number of users/orders/partners affected in a defined period. - Impact: expected per-user or per-order effect (normalized, e.g., 0.1 = small, 0.6 = medium, 1.0 = large). - Confidence: 0–1 based on evidence quality. - Effort: person-weeks. - ICE = Impact × Confidence × Ease (where Ease = 1/Effort proxy). 4) Sequence with constraints - Consider dependencies, experiment runtime, seasonality, and risk/guardrails (safety, compliance) that may override scores. 5) Allocate portfolio - Capacity split: e.g., 60% roadmap bets, 20% quick wins, 20% platform/data quality. - Reserve a small buffer for interrupts. 6) Communicate and revisit - Share the ranked list, assumptions, and what would change the decision. Re-score monthly or when new data arrives. Small numeric example (RICE) - Assume Reach is in thousands of orders over 6 weeks. - Project A: Improve ETA model - Reach = 300, Impact = 0.6, Confidence = 0.7, Effort = 4 → RICE = 300 × 0.6 × 0.7 / 4 = 31.5 - Project B: Promotions uplift model - Reach = 120, Impact = 0.8, Confidence = 0.5, Effort = 3 → RICE = 120 × 0.8 × 0.5 / 3 = 16.0 - Project C: Courier supply forecasting tooling - Reach = 200, Impact = 0.7, Confidence = 0.6, Effort = 6 → RICE = 200 × 0.7 × 0.6 / 6 = 14.0 - Ranking: A > B > C. If C unblocks future launches, you might sequence A, then C (for dependency), then B. When to override scores - Critical bugs, safety/compliance issues, SLAs with partners, or clear cost-of-delay outweighing the model score. Guardrails and validation - Define success metrics and stop-loss rules before starting. - Include experiment duration and ramp in Effort. - Track adoption and post-launch impact; revisit if metrics backslide. - Maintain a decision log with date, inputs, and owner. Example one-liner you can use in an interview - “I use RICE to produce a transparent first pass, then adjust for dependencies, risk, and cost-of-delay. I share the scoring sheet and decision log with stakeholders and re-score monthly as new data or constraints emerge.” ## What Good Looks Like in the Interview - Clear STAR story with quantified results and a small, low-risk pilot. - A prioritization method with a formula, a brief numeric example, and how you handle exceptions. - Explicit linkage to business KPIs and a collaborative communication plan.