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

My first response: do not say yes or no yet

I ask what the demo has to achieve and what the stakeholder wants the audience to see. Example: a sales lead asks for a new "export to PDF" report in next week's customer demo, and the real need is that customers see the reporting story. Often the idea has to be shown, not a working production feature.

Offer instead (in order of preference)

1. A scripted demo path: a clickable prototype or hard-coded flow, clearly labelled as a preview. Roughly 2 days, not 3 weeks.
2. A roadmap slide with a dated commitment.
3. Move the demo, only if the audience's decision depends on the feature working for real.

Is the extra value worth the disruption? (a quick scoring, with illustrative numbers)

I score each option 1 to 5 on how much it changes the audience's decision (value) and how much it risks (broken live demo, work pulled from committed items, rushed QA):

One week remains and the feature needs three, so a real build cannot fit; the choice is only which preview to show. I also ask how much the feature would change the audience's decision, because that sets how much disruption is justified.

Getting agreement from the people affected

A late request touches several teams, so I walk the critical path (the longest chain of dependent steps, which sets the earliest finish) with engineering, QA, product and whoever owns the demo environment. Steps marked (CP) are on it. Every step here waits for the one before it, so all five days are on the critical path and there is no spare time (float): a one-day slip anywhere moves the rehearsal into the demo day, which is why the freeze on day 4 is not negotiable:

When a senior stakeholder wants the real feature released immediately instead

If the team needs time to harden it (fix rough edges and test under real load), I propose partial delivery: release behind a feature flag (a switch that turns the feature on for chosen users only) for internal users or a small percentage of customers. A monitoring plan (what we watch, such as error rates) and a rollback (switching it off or reverting quickly) make that safe. I say it as protecting the stakeholder: "this gets you a first result this week and avoids an incident in front of your customers."

Direct answer. Technical debt is the future cost you accept by taking a shortcut now, like a loan you must repay with interest. Pick one real example where you deliberately took a shortcut, can name the cost, and followed through. Below is a story you can adapt (the details are illustrative; use your own).

Situation. Our team had a fixed launch date for a customer onboarding flow tied to a sales commitment. The clean design was a configurable rules engine (software where non-engineers change business rules through settings instead of code). It would take about 7 weeks, and 5 were left; the hardcoded version needed about 2.

The decision. I chose hardcoded rules in one module, covered by tests, supporting the three customer types we had signed. I made this call with my tech lead after listing options: a rules engine (too long), a spreadsheet-driven manual process (error-prone), or hardcoded rules with a clear seam (one well-defined place in the code where they can later be swapped for the engine without touching the rest).

Explaining the trade-off. To product and sales: "We can hit the date with three supported customer types. Adding a fourth will take about 3 days of engineering until we replace this." To engineers: the shortcut, where it lives, and the constraint it imposes. I did not describe it as a permanent solution.

The debt I took on.

• Every new customer type needs a code change and release.
• Rules logic sat close to onboarding code, which made it harder to test in isolation.

Making sure it got paid.

• A ticket in the backlog (the team's list of planned work) with an owner, the trigger ("before the fifth customer type or end of next quarter, whichever first"), and an estimate: replacing the hardcoded rules was about 15 days. At 3 days per new customer type, the extra hardcoding cost only equals the 15-day replacement after 5 further types (the eighth type in total), so cost alone would justify waiting much longer. I set the earlier trigger at the fifth type in total, about 6 days of extra cost by then, because each added type also raised regression risk in code that was hard to test in isolation, and because a date-based cap stops the debt drifting.
• A short decision record (a one-page note kept in the code repository): what we did, why, what we rejected, and the steps to replace it. The next team can then evolve it safely instead of guessing.
• A TODO comment pointing at the record next to the code.
• I raised it in quarterly planning with the cost of not paying it (each new customer type costing 3 days, against 5 weeks saved up front).

Result. We launched on the date. The fourth customer type arrived two months later; it took the predicted 3 days, which confirmed the estimate, and we scheduled the replacement for the next quarter, using the decision record.

What I would do differently: put the trigger in the roadmap when I made the decision, not afterwards.

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.

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
Technical debt is the future cost you take on when you choose a quicker, less clean way to build something. In product terms: you ship sooner today, and every later change in that area costs extra time, which shows up as slower features and more bugs. Ward Cunningham coined the metaphor in 1992: a little debt speeds things up if it is repaid promptly, and the danger is leaving it unpaid, because the extra effort every change costs is the "interest" (the loan is the shortcut itself).

When taking it on is acceptable

• It is a deliberate choice, not an accident from missing knowledge.
• The date is worth something real (a conference, a contract, a market window).
• The shortcut is contained and reversible, in an area few other things depend on.
• There is a named payback plan with a date and an owner.
  Not acceptable: shortcuts on security, data integrity or payments, or in a shared platform that many teams build on.

Track it
Keep a debt register (a simple shared list) with one row per item: where it is, what it costs us per week (interest), what breaks if we ignore it, rough fix effort, owner.

Prioritize it
Rank by interest relative to fix cost, plus risk. Illustrative item: a payment workaround costs 2 engineer-days (one person's working days) per release, with 2 releases a month, so 4 engineer-days a month. Fixing it takes 10 engineer-days, so the fix pays for itself in 10 / 4 = 2.5 months. That beats a cleanup that costs 10 days and saves 1 day a month (payback 10 months). Also reserve a recurring slice of capacity for repayment, for example 15% of each sprint: a team of 6 with 10 working days per sprint has 60 engineer-days, so 15% is 9 engineer-days per sprint. The percentage is a team policy you agree with product, not a benchmark; it keeps debt from competing with every roadmap item.

Communicate to the business
Avoid code talk. Say, using the same example: "Every release that touches payments takes 2 extra days because of a shortcut we took last year; with two releases a month that is 4 days a month. Fixing it costs 10 days once and pays back in about 2.5 months." Show cost, risk and payback, offer options (fix now, fix after the launch, live with it), and ask for the decision.

Pitfalls
Calling everything debt (messy code that never changes costs nothing), hiding debt from the business, and having a register nobody schedules from.