You are the only data lead for Q4, backing three initiatives: A) Cut courier cancellations by 10% before Nov 15; requires 1.5 eng-weeks; sponsored by VP Ops. B) Ship merchant quality dashboards by Oct 30; requires 2 eng-weeks; the Head of Merchant expects them for the QBR. C) Run a pricing uplift experiment by Nov 30; requires 1 eng-week; the CPO expects +2% revenue. Two eng-weeks are available before Oct 30 and one eng-week in November. A compliance review imposes a mandatory one-week lead time ahead of every launch. Design teams are shared across the initiatives and can only work on one at a time.

Tasks:

1. Rank and order the work with a concrete framework (for example RICE or WSJF). Spell out your assumptions and the decision rule you will apply.
2. Suggest the smallest viable scope for each initiative that still preserves expected impact and fits the constraints. Where do you trim scope, and why?
3. Write the stakeholder communication plan: what you commit to each leader, what slips, and how you get alignment on trade-offs. Include a sample status update and a script for declining.
4. A critical incident hits on Oct 25 and consumes 0.5 eng-week to repair a data quality problem affecting cancellations. Revise your plan. How do you renegotiate deadlines and handle risk without wearing down trust?
5. Set success criteria for your own performance (leading indicators, risks, contingencies).

Overview: This question tests prioritization, scope definition, stakeholder leadership, and resource and risk management skills for a Data Scientist in the Behavioral & Leadership category.

Solution

1) Ranking and Sequencing (Framework, Assumptions, Decision Rule)

Stated assumptions:

• "Eng-weeks" represent the engineering capacity I control (analytics, data engineering, instrumentation). Design is a separate shared constraint; only (B) requires design; (A) and (C) have little or no design dependency.
• A one-week compliance lead time means $\text{code complete} = \text{launch date} - 7 \text{ days}$.
• No extra hires or contractors; any additional capacity has to go through escalation.

Scheduling guardrail — Latest Start Date (LST)

• $\text{LST} = \text{Deadline} - \text{ComplianceLeadTime} - \text{Effort}$
• If the LST falls in October, the work must fit inside the 2 eng-weeks available before Oct 30; otherwise it must fit inside November's single eng-week.

LSTs calculated before any scope cuts:

• (B) launching Oct 30 means code complete by Oct 23; with effort 2.0, LST = Oct 9.
• (A) launching Nov 15 means code complete by Nov 8; with effort 1.5, LST ≈ Oct 25.
• (C) launching Nov 30 means code complete by Nov 23; with effort 1.0, LST = Nov 16.

Observation: October offers only 2 eng-weeks in total, and (B) at 2.0 eats all of it. November has just 1.0 eng-week, yet $(A) + (C) = 2.5 \text{ eng-weeks}$. So without scope cuts or renegotiation, the plan cannot work.

Ranking framework: WSJF (Weighted Shortest Job First)

• $\text{WSJF} = \frac{\text{Cost of Delay (CoD)}}{\text{Job Size (effort)}}$
• CoD is built from three components scored 1–10 relative to each other: business value, time criticality, and risk reduction/enablement.

Baseline WSJF before scope cuts (relative scores):

• (B) Dashboards: value 7, time 10 (QBR), enablement 5, so CoD 22; size 2.0 gives WSJF 11.
• (A) Cancellations: value 8, time 7, enablement 7, so CoD 22; size 1.5 gives WSJF ≈ 14.7.
• (C) Pricing: value 9, time 6, enablement 6, so CoD 21; size 1.0 gives WSJF 21.

Working decision rule:

• Step 1 (feasibility gate): honor hard deadlines and compliance — code must be complete by the required date, or the deadline gets renegotiated up front.
• Step 2 (WSJF within feasibility): order by descending WSJF, then adjust for design constraints.
• Step 3 (scope to feasibility): if the plan still doesn't fit, trim scope to the minimum that preserves expected impact; if it still doesn't fit, push for a trade-off decision with the sponsors.

Applying the rule:

• (B) carries a hard QBR deadline plus compliance, so it must claim an October slot.
• Making room for (A) and (C) forces scope cuts. The lowest-risk pattern is to shrink (B) to a QBR-ready MVP without advanced drill-downs, cut (A) to the leading root-cause fix plus monitoring, and simplify (C) to a server-side multiplier test.

High-level sequence before the incident:

• October window (2.0 weeks): 1.5 weeks on the (B) MVP, code complete Oct 9–23, then compliance Oct 23–30; the remaining 0.5 week, split before and after, covers pre-work on (C) or (A).
• November window (1.0 week): divided between (A) and (C) so each reaches code-complete ahead of its compliance window.

2) Minimal Viable Scope (MVP) and Where to Cut

(A) Courier cancellations (goal: −10% by Nov 15):

• MVP scope (cut to 1.0 eng-week):
  • Instrumentation and monitoring: a daily cancellation-rate monitor broken out by city and vertical, with spike alerts.
  • Richer root-cause taxonomy, such as structured reason codes pulled from the courier app and ops tools.
  • A fix or playbook aimed at the top one or two causes, for example merchant item unavailable or long prep time, a courier reassignment threshold tweak, or an ETA accuracy improvement behind a feature flag.
• Cut or deferred:
  • A full ML ETA rebuild, surgical fixes across multiple causes, and automated feedback loops. Rationale: one high-leverage fix paired with monitoring can capture most of the early impact.

(B) Merchant quality dashboards (needed for the QBR by Oct 30):

• MVP scope (cut to 1.5 eng-weeks plus focused design):
  • One landing page carrying 5 core KPIs — fulfillment rate, on-time readiness, cancellations, average prep time, defect rate — refreshed daily.
  • Filters for date range, region, and merchant segment, plus download/CSV export.
  • Role-based access for the QBR audience and a productionized pipeline with data quality checks.
• Cut or deferred:
  • Historical deep-dive pages, cohorting, alerting, time-series anomaly detection, and merchant drill-downs. Rationale: the QBR needs one consistent source of truth, not a fully self-serve v1.

(C) Pricing uplift experiment (Nov 30):

• MVP scope (held at 1.0 eng-week total):
  • A server-side price multiplier, such as +x% on the delivery fee or service fee, applied to a narrow region or category through the existing experimentation platform.
  • Predefined guardrails on conversion, take-rate, cancellations, and customer support contacts.
  • Telemetry covering exposure logs, assignment, and key outcomes, with no new UI or design work.
• Cut or deferred:
  • Multi-arm bandits, a dynamic price elasticity model, a broad rollout, and complex stratification. Rationale: demonstrate that +2% is achievable on a small slice first.

3) Communicating with Stakeholders

Commitments before the incident:

• VP Ops (A): commit to an MVP centered on the leading cancellation driver plus monitoring; code complete Nov 5; compliance Nov 8–15; launch Nov 15. Risk: if the top cause is not dominant, the impact may fall short of 10%; we will have the next-best fix pre-scoped as a contingency.
• Head of Merchant (B): commit to a QBR-ready dashboard MVP with code complete by Oct 23; compliance Oct 23–30; launch Oct 30, plus a clear list of post-QBR enhancements.
• CPO (C): commit to a narrow-scope server-side price test with code complete by Nov 20; compliance Nov 23–30; launch by Nov 30, and a guardrails and success review in early Dec.

Trade-offs, stated plainly:

• Meeting the (B) QBR date forces (B) to stay an MVP. The 0.5 October week that frees up pays for pre-work on (A) or (C). November's single week has to be split between (A) and (C), so both stay MVPs on tight schedules.

Illustrative schedule before the incident:

• Oct 1–4: pre-work on the (C) MVP (0.5 wk)
• Oct 9–23: build the (B) MVP (1.5 wks), then compliance Oct 23–30
• Oct 23–30: pre-work on the (A) MVP (0.5 wk), running alongside (B) compliance
• Nov 1–5: finish (A) (0.5 wk), then compliance Nov 8–15, launch Nov 15
• Nov 16–20: finish (C) (0.5 wk), then compliance Nov 23–30, launch Nov 30

Sample weekly status update (kept short):

• Status as of Oct 18:
  • (B) Dashboards: GREEN. 65% done; data model locked; front-end MVP underway. On track for code complete Oct 23, with compliance booked for Oct 23–30.
  • (A) Cancellations: YELLOW. Root-cause taxonomy validated; pre-work scheduled for Oct 23–30. Risk: quality variance in courier reason codes; mitigation: add a normalization step.
  • (C) Pricing: GREEN. Experiment design locked; exposure logging stubbed; 0.5 wk left in November.
• Risks/asks: none this week; design is fully committed to (B) until Oct 23.

Script for declining (a principled trade-off):

• "With 2 eng-weeks before Oct 30 and 1 eng-week in November fixed, plus a mandatory one-week compliance lead time, we can land the QBR dashboard and the cancellations MVP on their dates. Delivering the pricing test by Nov 30 as well would need another 0.5 eng-week or a further cut to the dashboard scope. If that capacity isn't available, my recommendation is to keep the dashboard MVP for the QBR and run the pricing test as scoped, accepting that it may slip a few days if the cancellations work overruns. Which trade-off would you prefer?"

4) Critical Incident on Oct 25 (0.5 eng-week): Replanning and Renegotiation

Impact: the Oct 25 data quality incident eats the 0.5 eng-week earmarked for (A) pre-work during Oct 23–30. (B) stays GREEN, since it was already code-complete on Oct 23. The result is a capacity crunch in November.

Revised capacity and schedule:

• October: (B) takes 1.5 wks and the incident 0.5 wk. No (A) pre-work happens in October.
• November (1.0 wk total):
  • (A) now needs the full 1.0 wk during Nov 1–7 to reach code-complete by Nov 7, then compliance Nov 8–15 and launch Nov 15.
  • (C) has 0.5 wk done from early Oct but still needs 0.5 wk to reach code-complete by Nov 22. No November capacity remains, so (C) slips unless capacity is added or (A) is cut further.

Renegotiation plan — early, transparent, and built on options:

• With the CPO on (C):
  • Lay out the options: (1) move the launch to Dec 7, with code complete Nov 30 and compliance Dec 1–7; (2) shrink (C) to a micro-canary confined to one DMA with a shorter observation window, accepting lower confidence, though it still needs 0.5 eng-week in early Dec; or (3) borrow 0.5 eng-week from another team between Nov 16–20.
  • Recommendation: slip to Dec 7 with guardrails and holdouts pre-computed, which protects (A) and keeps (B) delivered for the QBR. Commit to running pre-analysis and an experiment configuration dry run in parallel — both non-engineering tasks — so time-to-value stays short.
• With VP Ops on (A):
  • Confirm we remain GREEN by taking the full 1.0 wk of Nov 1–7. Offer a second tactical mitigation, a playbook, if the incident's root cause overlaps with cancellation drivers.
• With the Head of Merchant on (B):
  • Confirm the Oct 30 launch landed. Share the post-QBR enhancement backlog and the date work can resume, depending on how (A) and (C) turn out.

Actions that protect trust:

• Within 24 hours of the incident, communicate the impact, the new plan, and a clear rationale grounded in capacity math and compliance gates.
• Publish a one-pager with the revised timeline, the risks, and explicit asks, such as +0.5 eng-week by Nov 16 if the CPO wants to hold the Nov 30 date.
• Maintain a decision log recording who agreed to which trade-offs and when.

5) Success Criteria for My Own Performance

Leading indicators:

• Milestone adherence: code-complete dates measured against plan, and compliance submissions filed at least 1 business day before the cutoff.
• Risk burn-down: the open risk count falls week over week, and every risk has an owner and a mitigation.
• Stakeholder alignment: weekly status gets read, decisions are logged within 48 hours, and no surprises arrive unannounced.
• Quality gates: unit and integration tests pass; data validation checks for freshness, completeness, and invariants reach $\ge 99\%$ for (B); experiment telemetry completeness reaches $\ge 98\%$ for (C).

Outcome indicators:

• (B) dashboard usage by the QBR audience: at least 80% of intended viewers log in, the data is trusted, and there are zero critical defects.
• (A) a measurable drop in cancellations: at least −7% within 2 weeks as an interim target, with a plan to reach −10% using a second mitigation if needed.
• (C) the experiment runs with guardrails respected and yields a statistically valid read on the primary metric within 2 weeks of launch.

Key risks and contingencies:

• Compliance delays: submit early, keep a pre-checked artifact list, and hold a 0.25 wk buffer ahead of compliance.
• Design contention: hold (B) to a single layout, reuse components, and keep design out of (A) and (C).
• Data quality incidents: define triage SLAs in advance, keep rollback plans and feature flags ready, and freeze changes 48 hours before the compliance submission.
• Capacity shocks: agree on a cut list in advance, such as deferring (C) to Dec, and keep an escalation playbook for requesting +0.5 eng-week if an incident lands during a compliance window.

Summary of the revised post-incident plan:

• (B) launches Oct 30 — on track, with compliance Oct 23–30.
• (A) code-complete Nov 7; compliance Nov 8–15; launch Nov 15.
• (C) slips to Dec 7 unless +0.5 eng-week is added mid-November; its pre-work is done and it can resume immediately after (A).

The plan holds together, protects the most time-critical commitments, and preserves trust by making every trade-off explicit, quantified, and jointly agreed.