Cost-of-Delay Priority Scoring Prompt

This prompt is for product managers, engineering leads, and technical decision-makers who need to move backlog prioritization beyond intuition and into auditable, dollar-denominated trade-off decisions. The core job-to-be-done is to take a feature or initiative description and produce a structured cost-of-delay score with a per-day impact estimate, a confidence interval, and explicit assumptions. The ideal user is a human product manager who provides the input context—such as market data, customer feedback, and revenue projections—and critically reviews the model's output before it enters a roadmap or sprint planning tool. The required context includes a clear description of the feature, the customer segment it serves, the expected business outcome, and any known deadlines or dependencies.

Use this prompt when your prioritization process requires a consistent, repeatable method for comparing the economic urgency of different initiatives. It is particularly effective when integrated into a workflow where the output feeds into a structured decision log or a tool like Jira, Linear, or Airtable. The prompt is designed to be part of a larger system: a human provides the initial context, the model generates a scored analysis, and then a validation harness checks the output for completeness, flags overconfident estimates, and ensures all required cost dimensions are addressed. For example, if the model produces a cost-of-delay estimate without citing a specific revenue impact or customer churn risk, the harness should reject the output and request a revision. This prompt is not a replacement for financial modeling or a substitute for customer discovery; it is a reasoning accelerant that makes trade-offs explicit.

Do not use this prompt for real-time operational triage, such as classifying production incidents or support tickets, where a deterministic rules-based system is more appropriate. It is also unsuitable for tasks requiring precise financial forecasting, as the model's estimates are reasoned approximations, not calculated from a general ledger. The primary failure mode is overconfidence: the model may produce a specific dollar figure without adequate grounding. To mitigate this, always pair the prompt with an evaluation step that checks for missing cost dimensions and a human review step that validates the assumptions against known business data. The next step after reading this section is to review the prompt template and understand how to adapt its placeholders to your specific product context.

This prompt template is designed to be dropped directly into your AI harness. It instructs the model to act as a product economics analyst, estimating the cost of delaying a specific backlog item. The system prompt sets the role, the required output structure, and the critical constraint to avoid overconfidence. The user prompt provides the specific item to be scored. Before using this in production, you must replace every square-bracket placeholder with real data from your product management or engineering systems.

markdownCopy
## System Prompt
You are a product economics analyst. Your task is to estimate the cost of delay for a given backlog item. You must produce a structured output with a per-day cost estimate, a confidence interval, and a list of explicit assumptions. Do not invent data. If information is missing, state it clearly in the assumptions and widen the confidence interval. Be conservative; overestimating cost is more harmful than underestimating it.

## Output Schema
You must respond with a single JSON object conforming to this structure:
{
  "item_id": "string",
  "cost_of_delay_score": number, // 0-100, where 100 is maximum urgency
  "per_day_cost_estimate": {
    "amount": number,
    "currency": "string",
    "rationale": "string"
  },
  "confidence_interval": {
    "lower_bound": number,
    "upper_bound": number,
    "confidence_level": number // e.g., 0.9 for 90%
  },
  "key_assumptions": ["string"],
  "missing_information": ["string"],
  "cost_dimensions_considered": ["string"] // e.g., ["revenue", "user churn", "engineering time"]
}

## Constraints
- If you cannot estimate a dimension, exclude it from `cost_dimensions_considered` and note it in `missing_information`.
- The `confidence_interval` must widen as uncertainty increases.
- Do not output any text outside the JSON object.

## User Prompt
Score the following backlog item for cost of delay:

[BACKLOG_ITEM_TITLE]
[BACKLOG_ITEM_DESCRIPTION]
[ADDITIONAL_CONTEXT]

To adapt this template, start by mapping your internal systems to the placeholders. [BACKLOG_ITEM_TITLE] and [BACKLOG_ITEM_DESCRIPTION] should come directly from your issue tracker. [ADDITIONAL_CONTEXT] is where you inject relevant data that the model cannot know, such as the number of affected users, linked revenue, or the current sprint's capacity. The output schema is designed to be machine-readable; wire the JSON response directly into a priority queue or a dashboard. If your cost dimensions are fixed (e.g., always revenue, churn, and compliance), you can hardcode them into the system prompt to improve consistency.

Before deploying, run this prompt against a golden dataset of 10-20 items where you have a known, human-determined priority order. Check for three failure modes: overconfident estimates with narrow intervals on ambiguous items, missing cost dimensions that a human would have considered, and hallucinated monetary values. If the model consistently misses a dimension, add a reminder to the system prompt. If confidence intervals are too narrow, adjust the constraint language to force wider bounds when data is sparse. For high-stakes items where the cost of a wrong priority is significant, always route the output for human review before it updates a production queue.

The Cost-of-Delay Priority Scoring Prompt is designed to be called as a single step within a larger prioritization pipeline, not as a standalone chat interaction. In a typical implementation, a product management tool or backlog API sends a batch of feature candidates—each with a description, known constraints, and any available revenue or cost data—to an AI gateway. The gateway injects each item into the prompt template's [INPUT] placeholder, along with any organizational context such as current quarterly objectives or known market conditions in [CONTEXT]. The model returns a structured JSON object containing a cost-of-delay score, a per-day impact estimate, a confidence interval, and an explicit list of assumptions. This output is then parsed by the application and written back to the backlog item's metadata fields for sorting and review.

Validation is critical because overconfident or missing cost dimensions can distort the entire backlog ordering. Implement a post-processing validator that checks: (1) the confidence_interval is present and its lower and upper bounds are not identical, which would indicate false precision; (2) the assumptions array contains at least one item and no assumption is a verbatim restatement of the input; (3) the per_day_impact value is a positive number and falls within a reasonable range defined by your organization's historical data. If validation fails, retry once with a modified prompt that includes the validation error message in a [CONSTRAINTS] block, instructing the model to correct the specific failure. If the second attempt also fails, flag the item for human review rather than silently accepting a bad score. Log every scoring attempt—including the raw prompt, model response, validator result, and final accepted or rejected status—to enable drift detection and auditability over time.

Model choice matters here. Use a model with strong numerical reasoning and calibrated uncertainty expression, such as GPT-4o or Claude 3.5 Sonnet. Avoid smaller or older models that tend to produce point estimates without confidence intervals or that hallucinate revenue figures when none are provided. Set temperature to 0 or a very low value (0.1 maximum) to maximize reproducibility across scoring runs. If your backlog contains items that touch regulated revenue streams or compliance deadlines, route those items through a human review queue regardless of the model's confidence score. The prompt's [RISK_LEVEL] placeholder should be set to high for any item with compliance, safety, or revenue-recognition implications, which should trigger a mandatory human-in-the-loop step before the score is committed to the backlog. Do not use this prompt for real-time operational incident triage—it is designed for product and engineering backlog prioritization where the cost of delay is economic and strategic, not for minute-by-minute incident severity assessment.