Prioritizing a 62-Request BI Backlog with Three Analysts
A 300-person SaaS company has a BI backlog of 62 requests and three analysts. There is no intake form; requests arrive by Slack, email, and hallway conversations. The loudest stakeholder is sales operations, who wants a churn-risk model. Finance wants a monthly recurring revenue (MRR) and cost dashboard before the board meeting in eight weeks. Product wants a funnel dashboard. The billing system has 4% of accounts with mismatched contract values, and the CRM has duplicate accounts. The analysts spend about 40% of their time rebuilding recurring Excel reports. The VP of engineering, who owns the BI team, asks you to clear the backlog this quarter. There is budget for one contractor for 12 weeks and a possible purchase of a self-service BI tool.
1. What prioritization framework would you use, and what would you do first?
Read the worked answer
Clearing 62 requests with three analysts is not a capacity problem; it is a demand and readiness problem. I would introduce a single intake form with requester, decision supported, deadline, expected value, and data source. Then score each request on value to a company goal, effort, risk, and data readiness. Requests that depend on broken billing data score low on readiness regardless of who is asking. I would publish a quarterly roadmap with explicit capacity: roughly 60% planned work, 20% recurring reporting, 20% unplanned. First, I would inventory and automate the recurring Excel reports, because they consume 40% of analyst time and are low-risk wins. In parallel, fix the billing mismatch and CRM deduplication at the source, since both block multiple requests. The churn model and funnel dashboard wait until their data is trustworthy or until a contractor can take them. Saying no without a reason destroys trust; saying no with a score and a sequence builds it.
2. Finance needs the MRR dashboard in eight weeks, but 4% of billing accounts have mismatched contract values. Do you fix the pipeline first or deliver the dashboard?
Read the worked answer
I would not treat this as a binary choice. First quantify the materiality: 4% of accounts may be 1% of MRR or 15%, and that changes the decision. I would reconcile a sample, identify whether the mismatch is a timing issue, a contract-value sync failure, or a data-entry problem, and estimate the effort to correct it. If the variance is immaterial to the board metric, I would deliver the dashboard with a visible data-quality banner, a reconciliation page, and a known-issues list, while fixing the pipeline in parallel. If it is material, I would deliver a narrower dashboard on the clean subset and delay the full MRR view. I would also set a threshold and owner for the mismatch, because a dashboard that hides a known billing defect converts a data problem into a credibility problem. The right answer is a phased release with transparency, not a silent launch or an indefinite delay.
3. Sales operations and product both insist their request is urgent. How do you decide and communicate the sequence?
Read the worked answer
I would move the decision out of escalation and into a small BI steering group with finance, sales, product, and engineering. Each request gets a one-page case: decision supported, value, deadline, dependencies, and cost of delay. The group scores against company goals, not volume of asking. Sales operations' churn model may be high value but depends on clean account and usage data; product's funnel dashboard may be lower effort and unblock a current launch. I would sequence the funnel first if it is decision-ready, and give sales operations a defined discovery slot so the churn model has a real start date. The contractor can take one well-scoped build, not the ambiguous model. I would also publish the roadmap and the criteria in a shared channel. Transparency about why one request is second is what prevents the next hallway escalation.