Twelve Requests, No Priorities

Scenario

Example deployment: six weeks into a pilot with a hospital group, the FDE has a backlog of 47 requests: new reports, a mobile view, two more data sources, a custom export for finance, Spanish translations and "AI summaries for everything". Each came from someone senior. Meanwhile the pilot's original goal (reducing discharge delays by surfacing missing paperwork) is only half built.

What you see on the team

The FDE works evenings and switches tasks several times a day. Status updates list activity, not progress. The sponsor asks why the headline metric hasn't moved; users say the tool "does lots of things but not quite what we need". Product managers back home hear about the requests secondhand and can't tell which matter.

The common mistake

Saying yes to everything to keep stakeholders happy, building one-off features for whoever asked last, and treating the backlog as a to-do list instead of a set of hypotheses to triage.

Why it happens

• FDEs are measured, formally or informally, on customer happiness, and "no" feels risky.
• Requests arrive through many channels (hallway, email, executive meetings) without a single place to compare them.
• The success criteria agreed at kickoff aren't visible in day-to-day conversations.
• Building is more comfortable than negotiating.

The playbook

1. Re-anchor on the success criteria in writing with the sponsor: "Our goal for this pilot is X, measured by Y."
2. One intake and triage: every request goes into one list with requester, problem, and impact on the success metric. Review it weekly with the sponsor and a user representative.
3. Sort openly into: now (moves the metric), next (valuable, after the pilot goal), product (patterns for the product team), and no.
4. Protect focus time for the critical path; batch stakeholder conversations.
5. Send patterns home: write product feedback with evidence for requests that recur across customers.
6. Report progress against the metric, not task counts.

requests = [
    ("missing-paperwork alerts on ward dashboard", "metric", 5, 3),
    ("discharge checklist sync from EHR", "metric", 5, 5),
    ("mobile view", "nice", 2, 8),
    ("finance custom export", "other-team", 2, 3),
    ("AI summaries for every note", "nice", 3, 13),
    ("Spanish translation", "nice", 2, 5),
    ("bulk re-run of failed syncs", "metric", 3, 2),
]
def bucket(kind, value):
    return "NOW" if kind == "metric" else "PRODUCT" if value >= 3 else "LATER/NO"
for name, kind, value, effort in sorted(requests, key=lambda r: (r[1] != "metric", -r[2] / r[3])):
    print(f"{bucket(kind, value):8} value {value} effort {effort:2}  {name}")

NOW      value 5 effort  3  missing-paperwork alerts on ward dashboard
NOW      value 3 effort  2  bulk re-run of failed syncs
NOW      value 5 effort  5  discharge checklist sync from EHR
LATER/NO value 2 effort  3  finance custom export
LATER/NO value 2 effort  5  Spanish translation
LATER/NO value 2 effort  8  mobile view
PRODUCT  value 3 effort 13  AI summaries for every note

What to say

• To a senior stakeholder with a new request: "That's useful. Our pilot goal is reducing discharge delays; this doesn't move that yet. I've added it to the backlog we review with Dr Ahmed on Thursdays."
• To the sponsor: "We have 47 requests. Three move the discharge metric and I'd like to focus there for the next two weeks. Here's what I propose to defer, and why."
• To product: "Four of our hospital customers have asked for bulk re-runs of failed syncs; here's the evidence and the workaround cost."

Trade-offs

• Deferring requests disappoints some stakeholders; transparency about the criteria makes it a shared decision, not a personal refusal.
• Strict focus can miss an important new insight; the weekly triage is where goals can be deliberately changed.
• Some "nice" requests are cheap goodwill; allow a small, explicit budget for them.

Signals it's working

• The headline metric moves and the sponsor reports it upward.
• Stakeholders bring requests to the triage instead of to the FDE's inbox.
• Product feedback produces roadmap items that remove recurring custom work.
• The FDE's week has blocks of focused building time again.

Key points

• Scope creep kills pilots by diluting the work that moves the success metric.
• One intake, open weekly triage against written success criteria, and progress reports on the metric.
• Recurring requests are product signals; send them home with evidence.