Senior Business Intelligence Analyst Interview Preparation Guide - Lyft

Direct answer

Persuading someone senior to fund or change something means leading with the decision you want, naming the cost of the status quo explicitly, pre-empting the single most likely objection before it's raised, and sizing the ask (a phased or capped version) so agreeing feels lower-risk than it would if you asked for everything up front.

Structured elaboration

Anatomy of an executive ask:

1. Lead with the decision, not the narrative. State the ask early; don't make the sponsor wait for the punchline.
2. Name the cost of inaction explicitly, not just the benefit of acting.
3. Pre-empt the most likely objection (revenue impact, cost, risk) before someone else raises it in the room.
4. Size the ask to reduce perceived risk: a phased rollout, a pilot, or a capped budget is an easier yes than the full commitment.
5. Know your sponsor and your skeptic beforehand, and align the skeptic privately when possible.

Same competency, different scale. This shows up from small asks to board-level ones:

Worked example

Situation. At a mid-size company, an engineering manager proposed a platform consolidation project in a leadership review. A senior VP publicly dismissed it in the room as "solving a problem nobody has," undermining the pitch in front of the same audience needed for approval.

Stakes. Losing credibility with that VP risked not just this proposal but every future ask; meanwhile the underlying problem (duplicated infrastructure, rising support cost) was real and getting worse.

The influence moves.

• Didn't re-litigate in the room; took the public pushback as a signal to gather sharper evidence, not an invitation to argue live.
• Went back to the VP one-on-one, not to reopen the room's discussion but to ask directly what would change their mind, and learned the real objection was a past project's failed ROI, not this one's merits.
• Rebuilt the case to address that exact objection: capped the initial ask to a bounded pilot instead of the full six-month rewrite, with a defined stop-loss checkpoint.
• Brought the VP back in as a named reviewer of the revised plan, rather than resurfacing it as a surprise.

Resolution. The VP co-sponsored the revised, phased version at the next review. The earlier public criticism ended up making the final plan tighter and more credible, not dead.

What a senior candidate does differently. Doesn't treat public pushback as the end of the story or take it personally; treats it as the clearest possible signal of the real objection and goes to address it directly with the person who raised it, rather than only preparing a better slide for the same room.

Trade-offs and pitfalls

• Sequencing matters. Leading with the ask before the sponsor is aligned invites exactly this kind of public pushback; senior candidates often pre-wire the most skeptical stakeholder before the room, not after.
• Sizing matters. Asking for the full multi-month or multi-million commitment up front is a harder yes than a capped pilot with a defined checkpoint; the same case is more persuasive staged.
• "Strategic value" still needs a quantified comparison. Even initiatives without near-term revenue need some measured comparison (opportunity cost, cost of inaction), or the ask reads as a hunch.

Direct answer. Walk through your triage process for narrowing down what changed: what evidence you would gather first, the handful of underlying causes that pattern is usually explained by, and how you would confirm which one actually happened rather than guessing.

Structured elaboration. Start by gathering evidence that distinguishes "the plan changed" from "the plan is the same but the work it does grew": compare the current plan to a known-good baseline if one is available (many engines let you capture and diff plans, or at minimum you can re-run EXPLAIN and eyeball the operator shapes), and check whether the DATA changed (row count growth, a new skewed value, a bulk load) independent of any plan change. From there, the most common root causes for this "regressed with no application change" pattern are, in roughly descending order of how often they turn out to be the actual cause: statistics that went stale after a data change (a bulk load or a big delete that wasn't followed by a refresh); a cached plan compiled for an atypical parameter value now being reused for a much more typical, much less selective one (a parameter-sniffing regression); the DATA itself simply growing or shifting distribution past a threshold that used to favor one strategy and now favors another; and resource contention from something unrelated to this specific query (concurrent load, a maintenance job, disk pressure) that's slowing everything down and only looks query-specific because that's the query someone happened to notice first.

To confirm which one actually happened rather than just picking the most common cause and hoping: check statistics freshness and the estimated-vs-actual row counts at the plan's key nodes first, since that single check distinguishes the stale-statistics and parameter-sniffing causes (both would show a mismatch) from the pure-resource-contention cause (which typically wouldn't); if estimates and actuals both look reasonable and current, pivot to checking system-level resource metrics (CPU, I/O, lock waits) for the affected time window instead.

Worked example. A nightly report that quietly regressed after last week's data load added a disproportionate number of rows in one previously-small category is a textbook case: the statistics captured before the load still describe the smaller, more balanced distribution, so the optimizer's row-count estimate for that category is now badly wrong, and a plan built around that bad estimate (likely favoring an index-heavy strategy suited to the old, smaller volume) is now handling a much larger actual volume than it was ever appropriate for.

Trade-offs and pitfalls. It's tempting to jump straight to "just refresh statistics and see if that fixes it" without confirming that's actually the cause; that's a reasonable first cheap experiment to try, but treat a fix that "seems to help" with some skepticism until you've actually looked at the estimated-vs-actual gap directly, since a coincidental unrelated change (contention easing off on its own) can make an unrelated fix look like it worked.

I would track six KPIs—three quantitative, three qualitative—covering delivery, quality, and stakeholder engagement.

1. Throughput (quantitative): number of dashboards/reports delivered per sprint/month. Collect from task tracker (Jira/Asana) with standardized “done” definition. If throughput drops: run capacity review, remove low-value work, add cross-training, and negotiate scope/priorities with stakeholders.

2. Cycle Time (quantitative): average time from request to production. Collect timestamps from intake system and deployment logs. If cycle time rises: identify pipeline bottlenecks (data access, ETL failures, review delays), add automation (templating, CI for dashboards), or improve triage rules.

3. Data-quality Incidents (quantitative): count of production incidents (incorrect numbers, broken extracts) and Mean Time to Detect/Resolve. Source: incident tracker and monitoring alerts. If incidents increase: institute root-cause postmortems, strengthen testing (data contracts, unit tests), and add pre-release validation checks.

4. Stakeholder Satisfaction (qualitative): periodic NPS-like survey for report consumers (monthly/quarterly). Collect via short surveys linked in reports. If satisfaction low: conduct targeted interviews to surface pain points, quick UX fixes, and reprioritize high-impact reports.

5. Request Clarity Score (qualitative): % of requests needing rework due to ambiguous requirements, recorded by analysts in intake form. If high: improve intake template, run short discovery calls, and provide training to business partners on how to request analytics.

6. Collaboration & Knowledge Sharing (qualitative): measure via peer feedback and participation in knowledge activities (doc edits, lunch-and-learns). Track contributions in Confluence/Git and run quarterly 360 feedback. If weak: create documented standards, pair-programming sessions, and dedicate time for shared libraries/templates.

When negative signals appear, combine immediate mitigations (fix incidents, protect sprint capacity) with medium-term improvements (automation, intake/design patterns, stakeholder education) and measurable follow-ups (re-check KPIs after changes). Prioritize fixes by impact and effort, and make results transparent to stakeholders.

1. Completed Trips (market activity - rider + driver)

• Improvement: up (more fulfilled demand)
• Guardrail: Cancellation Rate (rises may hide churn)
• Frequency: Weekly (with daily spike alerts)

2. Gross Bookings / Revenue per Week (monetary health)

• Improvement: up
• Guardrail: Average Trip Distance or Surge % (big revenue increase driven by longer trips or extreme surge may mask poor underlying demand)
• Frequency: Weekly (daily for anomalies)

3. Rider Conversion / Booking Rate (rider-side experience)

• Improvement: up (more riders who open app book a ride)
• Guardrail: App Crash Rate or Time-to-Match (UX issues can lower conversion)
• Frequency: Daily

4. Active Drivers / Driver Utilization (driver-side supply & engagement)

• Improvement: Active drivers stable/increasing and utilization (trips per active driver) healthy
• Guardrail: Driver Churn Rate or Acceptance Rate (low acceptance suggests dissatisfaction)
• Frequency: Daily

5. Marketplace Match Time / Time-to-Pickup (efficiency & experience)

• Improvement: down (shorter match-to-pickup time)
• Guardrail: Cancellation Rate by pickup window (faster matches but more cancellations may indicate bad matches)
• Frequency: Real-time/Hourly for ops, summarized weekly

6. Fill Rate / Unfulfilled Requests (%) (demand-supply balance)

• Improvement: down (fewer unfulfilled)
• Guardrail: Average Wait Time and Surge Frequency (low unfulfilled but very high surge could show tight supply)
• Frequency: Daily (real-time alerts when spike)

For leadership: deliver the six metrics on one page with trend sparklines, week-over-week % change, and one-sentence insight + recommended action.

Direct answer

Build a mapping and identity-resolution layer between the two companies' product and customer models, assign new conformed surrogate keys for the unified entities, keep each company's original dimension tables live and queryable during a transitional period (so pre-merger historical reports remain reproducible exactly as before), and cut fact tables over to the unified conformed dimensions once the mapping is validated.

Structured elaboration

• Mapping approach: similar to conforming a product dimension across multiple sources, build explicit mapping tables (companyA_customer_id -> conformed_customer_key, companyB_customer_id -> conformed_customer_key) using a combination of exact-match keys where available (shared tax ID, email) and fuzzy matching with human review for ambiguous cases.
• Surrogate key generation for the unified model: mint entirely new conformed surrogate keys (not reusing either company's original keys, which avoids collisions and signals clearly that this is the unified, post-merger identity space) for every matched or newly-recognized entity.
• Conformed attributes: define, for any attribute both companies tracked differently (customer segment definitions, product categorization), an explicit reconciliation rule or a documented mapping between the two taxonomies, rather than silently picking one company's definition.
• Transitional layer, running both models in parallel: keep each company's original schema and historical fact tables intact and queryable (so a pre-merger report, re-run during the transition, still reproduces its original numbers exactly), while NEW fact data (post-merger) loads against the unified conformed dimensions; a transitional reporting layer can present a blended view by translating old-company-specific keys through the mapping tables when needed.

Worked example

Company A's customer CA-500 and Company B's customer CB-900 are identified as the same real-world entity (matched via a shared corporate tax ID) and both map to a new conformed customer_key = 100001. Pre-merger sales history from both companies remains queryable against their ORIGINAL dimension tables for historical continuity; post-merger sales load against the new conformed customer_dim, and a cross-period trend report joins pre-merger history through the mapping table to the conformed key to show this customer's full relationship across the merger boundary.

Trade-offs and pitfalls

Rushing to force ALL historical data into the unified model immediately (rather than running the transitional dual-model period) risks corrupting the historical record if the identity-resolution mapping has errors discovered later; keeping the original per-company schemas alive and immutable during transition gives a safety net to fall back on, at the cost of running two schemas in parallel for a period, which is real but bounded operational overhead worth paying for a migration of this risk level.

Direct answer: An optimization fence is any construct that stops the query planner from seeing across a boundary to reorder joins, push a predicate down, or otherwise optimize the two sides together; pre-Postgres-12 common table expressions (CTEs, named WITH-clause subqueries) were the canonical example, always materialized and therefore always fenced. Separately, an ORDER BY written inside a CTE only guarantees the order of that CTE's own result as computed; nothing in the SQL standard requires the outer query to preserve that order once it selects from the CTE, so relying on it to make a downstream LIMIT deterministic is a latent bug that can pass code review and testing and then break silently on a planner upgrade, a different engine, or even just a different query shape elsewhere in the statement.

Structured elaboration

What "fence" means concretely: a fenced CTE is optimized as its own self-contained unit first, independently of the rest of the query, and only the finished result is handed up. A predicate in the outer query that would have let an index narrow down the CTE's own scan can't reach across the fence to do so; a join that would have been more efficient reordered around the CTE's contents can't be reordered, because the planner treats the fenced region as an opaque black box.

-- Pre-12 Postgres (or MATERIALIZED anywhere): expensive is computed in full before the outer filter runs
WITH expensive AS (
  SELECT * FROM large_table WHERE complicated_expr(...)
)
SELECT * FROM expensive WHERE small_col = 5;

-- Rewritten to remove the fence: an inline derived-table subquery was never fenced this way
SELECT * FROM (
  SELECT * FROM large_table WHERE complicated_expr(...)
) t
WHERE small_col = 5;

On Postgres 12+, the same effect is available without rewriting: add NOT MATERIALIZED to let the planner inline the CTE and push small_col = 5 down; add MATERIALIZED to force the fence back on intentionally (for instance, to guarantee single evaluation of an expensive or volatile CTE referenced more than once).

The ORDER BY-inside-a-CTE trap:

-- Risky: relies on the CTE's own ORDER BY surviving into the outer LIMIT
WITH ranked AS (
  SELECT id, score FROM scores ORDER BY score DESC
)
SELECT * FROM ranked LIMIT 3;

Nothing in the relational model guarantees this returns the top 3 by score. A CTE's result is logically a set (or, more precisely, an unordered rowset once you select from it in a further query), and an ORDER BY inside the CTE only defines the order of that CTE's own output, not a property the outer SELECT ... LIMIT is obligated to preserve. In practice this often "just works," which is exactly what makes it dangerous: it can pass every test you run against it on your current engine and version, then silently pick the wrong 3 rows after a planner change, an engine migration, or a query rewrite elsewhere in the same statement that changes the plan shape.

The correct fix, two ways:

-- Fix 1: repeat the ORDER BY at the level that actually applies the LIMIT
WITH ranked AS (
  SELECT id, score FROM scores
)
SELECT * FROM ranked ORDER BY score DESC LIMIT 3;

-- Fix 2: make the order an explicit data column via ROW_NUMBER, then filter on it
WITH ranked AS (
  SELECT id, score, ROW_NUMBER() OVER (ORDER BY score DESC) AS rn FROM scores
)
SELECT id, score FROM ranked WHERE rn <= 3 ORDER BY rn;

Fix 1 is the minimal correct version: put ORDER BY next to the LIMIT that depends on it, not one level removed inside the CTE. Fix 2 goes further by turning "the order" into an actual column (rn), which survives any amount of further querying because it's data now, not a side-channel property of how the result happened to be produced; this is the safer choice once the ranked result needs to be joined, filtered, or re-aggregated further before the final LIMIT is applied.

Worked example (executed in DuckDB)

Five rows with scores 50, 90, 70, 60, 80. All three versions (the risky pattern, fix 1, and fix 2) returned the identical top-3 result (scores 90, 80, 70) when run against this engine and this simple query shape. That's the honest and slightly uncomfortable part of demonstrating this trap: it is not something you can reliably force to fail on demand, because whether the risky pattern happens to work depends on planner internals that are neither part of the SQL standard nor something a worked example can guarantee reproduces a failure. The takeaway isn't "I proved it breaks here"; it's that fixes 1 and 2 are correct by the language's actual guarantees regardless of engine or version, while the risky pattern is correct only by accident, and accidents are exactly what regress silently after an upgrade.

Trade-offs & pitfalls

• Treat "it happened to return the right order in testing" as zero evidence that the risky pattern is safe; the standard's guarantees, not observed behavior on one engine and version, are what to design against.
• MATERIALIZED (forcing a fence) and NOT MATERIALIZED (removing one) are Postgres-12+-specific keywords; other engines need a rewrite (derived-table subquery, or an explicit temp table for a guaranteed-single-evaluation fence) to get the equivalent effect.
• Oracle exposes a similar override via undocumented /*+ MATERIALIZE */ and /*+ INLINE */ hints placed inside the factored subquery itself, not as top-level WITH-clause syntax the way Postgres's keywords are; don't assume the syntax transfers even when the concept does.
• The ORDER BY trap compounds with LIMIT specifically; an ORDER BY inside a CTE that's never followed by a LIMIT anywhere downstream is comparatively harmless, since the full result set eventually gets consumed regardless of order, but the moment a LIMIT enters the picture at any level, order becomes load-bearing and needs to be guaranteed at that level, not assumed from upstream.

Direct answer

I would first confirm the drop is real, then decompose it, then isolate the pricing effect, in this order: (1) measurement check (did the definition, data pipeline or currency treatment change?), (2) mix vs rate decomposition (did the blend of what is sold change, or did the rate on the same thing fall?), (3) pricing exposure analysis (compare markets and segments that got the update at different times with ones that did not). Take rate is the share of the order value that the marketplace keeps: net revenue divided by GMV (gross merchandise value, the total value of orders placed). A step change on the rollout date that appears in every segment points to price; a gradual drift that disappears inside segments points to mix; a break in both numerator and denominator on the same day points to measurement.

Step 1: measurement (cheapest, and can end the investigation)

• Reconcile GMV and net revenue for the affected markets against the finance ledger (the accounting system of record for money in and out); check whether the metric's definition changed (tips, taxes, delivery fees or refunds newly included in GMV inflate the denominator and lower the rate).
• Check currency conversion, late-arriving settlements (payments posted in a later period than the orders they belong to), duplicate or missing data loads, and whether new revenue lines (ads, subscriptions) are or are not in the numerator.
• Early signal: the drop is in the warehouse table but not in the ledger, or an overnight step appears in unaffected markets too.

Step 2: mix vs rate (the central analysis)

Take rate overall = sum over segments of (segment share of GMV x segment take rate). Segments could be order size band, category, merchant type, new vs repeat customers. A fall in the blended rate can come from the rates falling (rate effect) or from GMV shifting toward lower-rate segments (mix effect). Illustration with two segments, using before-shares to weight rate changes and after-rates to weight share changes:

• Blended before: 0.5 x 24.0% + 0.5 x 16.0% = 20.0%. After: 0.4 x 22.5% + 0.6 x 15.0% = 9.0% + 9.0% = 18.0%. Total change: -2.0 points.
• Rate effect = 0.5 x (22.5 - 24.0) + 0.5 x (15.0 - 16.0) = -0.75 - 0.5 = -1.25 points.
• Mix effect = (0.4 - 0.5) x 22.5 + (0.6 - 0.5) x 15.0 = -2.25 + 1.5 = -0.75 points.
• -1.25 + -0.75 = -2.0, so the two effects account for the whole change. In this made-up case, 62.5% is rate (price) and 37.5% is mix, so I would not credit the pricing update with the full two points.
• Order matters. The split above weights rate changes by before-shares and share changes by after-rates. Reverse the weighting (rate changes by after-shares, share changes by before-rates) and you get rate effect = 0.4 x (-1.5) + 0.6 x (-1.0) = -1.2 points and mix effect = (-0.1) x 24.0 + 0.1 x 16.0 = -0.8 points, which again sum to -2.0 but split 60% / 40%. The total is fixed; the attribution shifts a little with the convention, which is why the convention goes in the metric definition.
• Early signal: if segment rates are flat but shares moved, the pricing update is not the cause; but also check whether the update itself caused the mix move (for example, higher fees on small baskets pushed those orders away), which is a second-order pricing effect.

Step 3: isolate the pricing effect

• Staggered rollout or untreated markets: a staggered rollout means markets receive the update on different dates, and a treated market is one that has received it. Compare treated markets with similar untreated ones before and after (difference in differences: the treated change minus the untreated change). Illustration with made-up numbers: treated markets go from a 20.0% to an 18.0% take rate (-2.0 points); similar untreated markets go from 20.5% to 20.0% (-0.5 points). The pricing update accounts for -2.0 - (-0.5) = -1.5 points, and the other 0.5 points is a drift that hit every market. If untreated markets fell as much as treated ones, the difference would be about zero and the cause is not the pricing update.
• Effective vs list rate: the list rate is what the price card says; the effective rate is what was actually collected, net revenue over GMV. Compute the realised rate on orders against the new price card. Illustration: a 20.0% list rate on small baskets, with the fee waived on 15% of those orders, gives an effective rate of 0.85 x 20.0% = 17.0%. If list went up and the realised rate went down, look at discounts, waivers (fees skipped for some orders), fee caps (a maximum fee per order) or mislabelled tiers.
• Timing shape: a step on the effective date vs a gradual slide; and the same pattern by market, so one market's local promotion is not mistaken for the cause.
• Volume response: did GMV or order count rise (a deliberate trade of rate for volume) or fall? A lower take rate with higher GMV can be net positive; compare net revenue in dollars, not the rate alone.

Decision

Report net revenue dollars and contribution alongside the rate. If the drop is mostly measurement, fix the definition and restate the history. If mix, decide whether the new mix is desirable. If price, quantify the volume bought with it, then decide whether to roll back or keep the update.

Pitfalls

• Reading a take rate move as price without checking the denominator.
• Ignoring that mix and rate are order-dependent in the decomposition; state your convention.
• Comparing markets that differ in category mix or maturity, which breaks the control group.

Direct answer

Don't treat it as narrative versus dashboard, give both, but change which one is the default view. Lead with a short narrative stating the decision-relevant takeaway, and keep the full dashboard one click or one slide away so the stakeholder can self-serve or verify a number without you gatekeeping the underlying data.

Structured elaboration

• Diagnose why they want the full dashboard. It could be distrust of your synthesis, a habit from before narrative summaries existed, or a genuine need to slice the data themselves.
• If it's distrust, that is a relationship problem to fix with a track record of accurate synthesis over time, not a formatting problem you can solve in one deliverable.
• If it's a genuine self-serve need, make the narrative the front page and link the dashboard as the appendix rather than dropping the narrative altogether.

Worked example

A BI analyst's sponsor insists on seeing the full 40-metric dashboard every week. The analyst starts sending a 3-bullet narrative email ("signups up 8% week over week, driven by the paid channel; retention flat; one metric to watch, refund rate ticked up half a point") with the dashboard link at the bottom. After a month the sponsor mostly replies to the narrative and stops opening the dashboard link most weeks, but keeps it available for the weeks they want to check a specific number themselves.

Trade-offs and pitfalls

Removing the detailed view entirely risks looking like you're hiding something. Always leading with the raw dashboard loses your chance to frame the interpretation, and the stakeholder may draw their own, sometimes wrong, conclusions from the unframed numbers.

What the interviewer probes next

Expect a follow-up on what you'd do if a stakeholder explicitly says they don't trust your narrative and want to see everything raw, every time.

Framework: treat this as a product-investment decision — gather evidence, estimate impact, validate with experiments, then recommend with ROI and risk.

1. Clarify scope & success criteria

• Define the interaction (what problem it solves, target user segments, primary KPI e.g., conversion or retention).
• Constraints: engineering effort, time, legal/privacy, UX guidelines.

2. Data to collect

• Product telemetry: current funnels, activation rates, DAU/WAU, session length, feature usage by cohort.
• Business metrics: conversion to paid, average revenue per user (ARPU), churn, LTV.
• Qualitative: competitor demo transcript, user interviews, support tickets, NPS comments.
• Operational: implementation cost estimates, expected maintenance.

3. Hypothesis & leading metrics

• Hypothesis: "Adding interaction X increases activation by Y% and reduces churn by Z% for segment S."
• Leading metrics to forecast ROI: activation lift (first-week conversion), engagement depth (time on task, events/session), short-term conversion uplift, retention delta (30-day), funnel drop-off reduction.
• Map metric changes to revenue: ΔARPU and retention → ΔLTV; use cohort LTV model.

4. Experiments/pilots

• Instrument prototype as feature-flagged A/B test (control vs variant). If risky, run an opt-in pilot with power users.
• Variants: simple mimic of competitor, smaller/lightweight version, and control.
• Sample size & duration: compute power for expected minimum detectable effect (e.g., 3–5% lift), run across representative segments for 2–4 weeks.
• Track secondary metrics for harm (error rates, task abandonment, support volume).
• If backend impact is large, run a business-simulated pilot in a sandbox environment and usability sessions before A/B.

5. Analysis approach

• Pre-register metrics and success thresholds; use sequential testing guardrails.
• Use uplift modeling, cohort analysis, and segmented treatment effects (by acquisition channel, device).
• Back-of-envelope ROI: incremental revenue = users_exposed * conversion_lift * ARPU; incremental cost = development + infra + ops. Compute payback period and NPV over expected feature lifetime.

6. Presentation to leadership

• One-page executive summary: recommendation (Go/No-Go/Iterate), top-line projected ROI, key assumptions and sensitivity ranges.
• Visuals: funnel before/after, cohort LTV scenarios, A/B results with confidence intervals, cost breakdown, timeline and risks.
• Ask for a clear decision: pilot approval, budget, or kill. Provide contingency plan (roll-back criteria, monitoring dashboard).
• Deliverables: BI dashboard with live experiment metrics, SQL queries and data lineage, and a reproducible ROI model so leadership can adjust assumptions.

This plan balances quantitative forecasting, rapid validated learning, and clear decision criteria suited for BI-driven product decisions.

I would start by diagnosing the problem before trying to fix it. I would interview both teams, review the timeline, and map every requirement change, handoff, and missed dependency. I would look for evidence of changing scope, unclear ownership, or missing acceptance criteria rather than assuming the issue is attitude.

Then I would reset the operating model. First, create a single source of truth for requirements and decisions. Second, define ownership for each deliverable and each handoff. Third, add a lightweight change-control step so new requirements are reviewed, sized, and approved before they disrupt the plan. I would also establish a regular checkpoint where both teams see the same risks and blockers.

If I found that the real problem was unclear handoffs, I would introduce a standard handoff template with the deliverable, due date, acceptance criteria, and owner. For example, if design changes a flow, engineering should see exactly what changed and what stayed stable. That shifts the teams from blame to shared execution and usually stabilizes delivery quickly.

For example, say the two teams are the Checkout team and the Fulfillment team, and the requirement that kept shifting was how a partial refund should be represented in the order-status payload. A filled-in handoff entry might read: deliverable: order-status payload v2 for partial refunds; due date: the 14th; acceptance criteria: refund_amount and refund_reason fields present and validated against three sample orders; owner: the Checkout API lead. With that entry in place, Fulfillment could build against a fixed contract instead of a moving target, and in the next release cycle the number of last-minute payload changes dropped to zero, because any change now had to go through the same template before it reached Fulfillment.