Delivery Prioritization: Scope, Speed, Quality, and Cost Questions

Direct answer
Ship the smallest thing that proves agents save time: for each incoming email, show a short bullet summary beside the ticket, with a thumbs up or down. Define success in numbers before building, test on real past emails in week 1, and have a fallback if the evidence is weak. With one engineer, the main risk to the date is integration plus summary quality, not model choice.

What the MVP produces (illustrative)
Incoming email: "I was charged twice for my March plan (order 4821). I need the refund before Friday for our finance close. I wrote on Monday and got no reply."
Summary shown to the agent:

• Double charge on March plan, order 4821
• Wants refund by Friday (finance close)
• Wrote Monday, no reply yet: urgent
  Every figure and date in these bullets appears in the original email; "urgent" is the only inference, drawn from the Friday deadline and the unanswered message.

In the MVP

• One summary of 3 to 5 bullets per email (plus the latest message when a thread is long).
• Shown in the existing agent screen, using a language-model API call (the app sends the email text to a hosted AI model over the internet and gets the summary text back).
• A rating button, and logging of summary, rating and edits.
• A kill switch (one setting that turns the feature off immediately).

Out of the MVP
Multiple languages, attachments, custom tone, automatic routing, fine-tuning (further training the model itself), analytics dashboards.

Six-week plan (illustrative)

How we know it worked
Agree numeric targets with the executive before launch. Illustrative targets for the pilot:

• Usage: at least 6 of the 8 pilot agents open summaries on most working days in week 5.
• Accuracy: read 100 sampled summaries; at least 80 rated accurate by agents, and no more than 5 with an invented or missing key detail.
• Speed: median time to first reply at least 10% below the week-1 baseline.
  If usage and accuracy are met but speed does not move, extend the pilot rather than declare success. Pick the real numbers with the executive and the support lead; these are examples of the form.

Top risks and handling

• Summaries that miss or invent a key detail: show the original email alongside; make every bullet reuse the email's own key terms and figures (order number, dates, amounts) so each can be checked at a glance; if the week-2 comparison shows the abstractive bullets invent details, ship the extractive approach (quoted sentences) instead; keep summaries short; review a sample weekly.
• Customer data and privacy approval: raise on day 1 and pick an approved provider.
• Helpdesk integration surprises: the spike above.
• One engineer is a single point of failure (if they are ill or leave, work stops): write down decisions; keep scope with slack.

Direct answer. I decide what to pull by comparing what each feature adds to launch value against the risk and effort to finish it, protect the core user journey, and communicate the cut early with a date for the return. Afterwards I check outcomes against measures set before launch. Below is a story you can adapt (details illustrative).

Situation. Two weeks from a fixed launch date for a customer-facing reporting product, four features were unfinished and the team could finish about three.

Choosing what to cut. I scored each feature on user value, launch risk and days left to finish:

The first three total 3 + 2 + 4 = 9 days and the fourth 3, so 12 days of work against about 9 available, a shortfall of 3 days. I cut by value first, because ranking by risk and effort only breaks ties: the three features rated High or Medium for value carry the launch, while custom themes was the only Low-value item, with Low risk either way. Cutting it removes exactly the 3-day shortfall. I pulled it because it served the fewest users and the launch did not depend on it. I weighed three sides: customers (does the core job work?), the business (does the date matter for a commitment?) and engineering (will we ship safely, or push quality down?). Keeping it would have moved the date by at least those 3 working days, plus retesting and release-note time, all for the lowest-value piece, so I rejected that.

Communication.

• Stakeholders: what is cut, why, when it returns.
• Users: release notes and a roadmap line (an entry in the published plan saying the feature is coming), not silence.
• Team: credit for scoping hard rather than rushing.

Verifying afterwards. Before launch, I set measures: adoption of the core dashboard, support tickets that mention themes, and requests for the cut feature. Before launch I also wrote down what would prove the cut wrong, so the check was not a judgement made after the fact. The value ratings in the table came from evidence, not preference: beta usage data (which screens customers opened most), the themes requests in the support log, and what the three pilot customers had asked for. Illustrative thresholds, agreed with product before launch: the cut was wrong if themes came up in more than 5 percent of support tickets in the first month, if two or more customers named it as a reason to hold back or churn, or if the core dashboard adoption target was missed because of the missing feature. After a month, themes appeared in 2 of 120 tickets (under 2 percent, an illustrative result) and no customer cited it, so none of the thresholds was crossed and the call held. Had a threshold been crossed, I would have reprioritized it, meaning moved it up the list of planned work, and put it in the next release. A single month of tickets is a small sample, so I would keep the request count visible for another quarter before treating the decision as closed. Launch risk, in the table, means the chance that finishing a feature in a hurry would cause problems at launch.

What I would do differently: involve the customer-facing team earlier in the cut list.

First, pin down what "50 percent" and "impact" mean

I ask the executive two questions: is 50% measured in effort or in feature count, and which measurable result must survive? Say the goal is lifting the share of new users who finish setup (activation rate) from 30% to 36%. The cut is a means; the metric is the commitment.

What I keep, cut and why (illustrative)

An onboarding revamp: 8 items, 40 person-weeks (pw; one person working one week).

How I rate contribution: from the setup funnel (where new users drop out) and a handful of user tests. In this example most drop-off happens at the signup form and at the first task, so items that fix those rate High, and items that only help later or help other metrics rate Low. I turn the ratings into points (High 3, Medium 2, Low 1) and divide by effort to get points per person-week, then keep the best until the effort reaches half.

Kept: 4+6+3+2+5 = 20 person-weeks, which is 50% of effort even though it is 5 of 8 items (about 63% by count). Every kept item scores at least 0.40 points per pw and every postponed or cut item scores 0.25 or lower, so the line falls where the ratings say. The progress bar is Low but kept because at 2 pw it is cheap and strengthens the checklist; the video tours are Low and cost 6 pw. Cutting by effort is what the executive asked for.

Redeploying the team

With 5 engineers, 20 person-weeks is roughly 4 weeks of work, not an exact figure because of coordination. I would not leave people idle or split the same work thinner: ship the thin slice earlier, put 1 engineer on measurement and fixes, and move the others to the next committed priority. Bringing in more people to the reduced scope would repeat the problem.

Judging afterwards

• Before launch: baseline 30%, target 36%, and a floor (the minimum result I would still call acceptable) of 33% agreed with the executive (all illustrative).
• Check at 2 and 6 weeks after launch, with a guardrail (a second metric that must not get worse) such as support tickets not rising.
• Decision rule: below 33%, pull one postponed item forward (the wizard first); at or above 36%, the remaining items stay on the backlog. Between 33% and 36%, the release is acceptable but short of target: I keep the postponed items on the backlog, check the funnel again at week 6, and pull one forward only if the gain has stalled below 36% by then.

Situation

I was the product owner for a payments reconciliation feature for a partner. They asked to go live in 3 weeks; our plan was 6 weeks, covering 6 payment types. (This is a sample story; use a real one with your own numbers.)

Task

Protect the quality of what we delivered without losing the partner's trust, and agree a new plan.

Action

• Showed the impact with evidence, not opinion. I replayed one month of the partner's real refund records against the early build: 9 of 60 refunds posted wrongly because the refund handling was unfinished. That made the risk concrete.
• Decided what to drop. I ranked the 6 payment types by their share of the partner's volume with the engineering lead. The 4 highest-volume types were completable in 3 weeks (they were the simpler ones, about 2.5 of the 6 weeks of planned effort between them, with the 2 low-volume types holding the harder edge cases). The other 2 (low volume) moved to week 6. The arithmetic: the 4 types needed about 2.5 weeks of effort, leaving half a week of the first 3 weeks to start on the harder two, so their remaining effort of about 3.5 weeks, less that half week, finished at week 6.
• Offered, did not just refuse. The script: "I cannot promise all six on week 3 without risking mis-posted refunds. I can promise four on week 3 and the rest on week 6. Which helps you more?"
• Kept trust. A short weekly status, and the written plan agreed by their lead.

Result

The partner accepted. The four types went live in week 3 with no reconciliation incidents in the first month, and the remaining two shipped in week 6 as agreed. The partner later asked us to estimate their next release the same way.

What I would do differently

Bring the evidence earlier, in the first conversation, not after the pushback.

The same approach in other situations

• Saying no to senior stakeholders: lead with what you can do and the date; show the cost of the alternative.
• Analysis taking longer than expected: send interim findings on the original date: what is known, what is not, the new date and confidence.
• Unrealistic short-notice request (hypothetical): state what fits in the time given, name the risk of the full ask, and propose a staged plan with dates.

Direct answer
Choose a project where the date or headcount really was fixed. Say how you chose the first slice (what the customer could not do without, plus the part most likely to blow up), what you knowingly gave up, and how often stakeholders heard from you. The story below is an illustrative shape to adapt with your own facts.

Situation and task
A team of four had 6 weeks to ship a self-serve invoice download for customers heading into audit season. In week 3 one engineer was pulled onto the outage rotation (the on-call duty of fixing production incidents), so we lost a quarter of our capacity.

What was built first, and why

• Week 1: listed the 12 requests and asked of each: does the customer's audit task fail without it, and is it risky or unknown?

The other six requests followed the same test and went on a later list.

• First: the riskiest unknown (generating PDFs from billing data) as a thin end-to-end path (the simplest version that works from billing data through to a downloaded file), then one download button. High value and high risk both pointed there.
• Left out from the start: bulk download and custom branding. Email delivery stayed on the plan as a stretch item until week 3, when the capacity loss made it the item we dropped.

Trade-offs accepted

• Automated tests only on invoice totals; manual checks on the three most-used invoice types.
• Bulk download became a documented "later" item, and support ran it by script in the meantime.
• Plain layout, no polish.

Keeping stakeholders informed

• A weekly four-line note to the product lead and customer success: done, next, biggest risk, decision needed.
• The day capacity dropped, I brought two options (drop email delivery, or move the date one week) and a recommendation. They chose to drop email delivery.
• A week-3 demo to two friendly customers (customers happy to try early versions and give candid feedback) to catch surprises early.

Result and lesson
Shipped on the committed date (day 42 of 42). Quote your own measured outcome here, for example how many audit-season requests customers handled themselves instead of asking support. Lesson: raise a capacity risk the day you see it, and always arrive with options.

Internship or early-career version
Same shape at smaller scale: a 10-week internship project to build an internal reporting dashboard.

• Technical choices: an existing chart library and a nightly spreadsheet export instead of building a data service.
• Trade-offs: tests only on the number calculations; no mobile layout.
• Risk communication: in week 3 I showed my mentor that a change to the export format would break the dashboard, and we agreed a fallback.
• Lessons: ask for a fixed weekly check-in, write down what was cut, and demo early.