Prioritize competing engineering requests

Scenario

You work as a data science or analytics partner for several engineering teams. Two or more teams come to you at the same time asking for analytics or experimentation work, and their requests clash on schedule and scope.

Question

1. How do you choose which request gets priority?
2. What details do you collect from product, engineering, or other stakeholders before you commit?
3. How do you explain the tradeoffs, timelines, and final call back to the teams?
4. What do you do if a senior leader pushes you to change your prioritization?

Overview: This question tests a data scientist's ability to prioritize, manage stakeholders, communicate tradeoffs, and lead when juggling competing analytics and experimentation requests.

Solution

What a strong answer demonstrates

• You rank work by business impact, urgency, risk, and effort, not by who is loudest.
• You build a transparent intake and prioritization framework and share it with others.
• You stay ahead of stakeholder needs and reduce delivery risk.

Step-by-step approach

1) Clarify each request (don’t take vague asks at face value)

For each team, quickly establish:

• Goal: what decision will this analysis or experiment support?
• Success metric: which metric should move, by how much, and by when?
• Time sensitivity: hard deadlines such as launches or exec reviews, or just nice-to-have.
• Effort & dependencies: data availability, instrumentation needs, engineering work, approvals.
• Risk: possible revenue or user harm, legal or privacy exposure, correctness risk.

2) Use a scoring rubric (lightweight, repeatable)

Example rubric (score 1–5):

• Impact (revenue, retention, advertiser outcomes)
• Confidence/clarity (is the problem well-defined?)
• Urgency (launch gating vs exploratory)
• Effort (lower effort = higher score)
• Risk reduction (does it prevent major harm?) This can be converted into a simple priority score such as:

$$\text{Priority} = (Impact + Urgency + RiskReduction + Clarity) - Effort$$

3) Offer choices, not just “yes/no”

When two requests compete, propose:

• Option A: Complete request 1 in full now; schedule request 2 for the next sprint.
• Option B: Deliver a thin-slice for request 2 (minimum viable analysis) now, then a deeper follow-up.
• Option C: Parallelize by reordering work: request engineering instrumentation first while you analyze existing data.

4) Make tradeoffs explicit (and write them down)

Communicate:

• What you will deliver (scope)
• When it will be done
• What you are not doing (de-scoped items)
• Risks and assumptions A short one-page write-up prevents the decision from being reopened later.

5) Handle escalation and senior pressure

• Ask for the decision criteria: “If we override, which goal are we optimizing—revenue this quarter, launch readiness, or platform risk?”
• Provide the opportunity cost: “If we do X, Y slips by 2 weeks; expected impact is …”
• If leadership insists, align, execute, and record the decision and rationale.

Common pitfalls

• Saying yes before clarifying success metrics.
• Prioritizing based on relationship instead of impact.
• Failing to de-risk through instrumentation checks and data quality.
• Failing to set expectations around iteration versus one-shot perfection.