PromptBase
PromptBase SelectGet Select
Close icon
General
Home
Marketplace
Create
Hire
Login
Chat
Sell
Explore

Prompt Details

Model
Chat - (gpt-5.6)
Token size
1,283
Example input
[ROLE_CONTEXT]: I am a product manager coordinating one designer, four engineers, and a shared data analyst. The VP Product sets roadmap priority; Engineering assigns people. I need a brief for our Monday portfolio meeting. [CURRENT_COMMITMENTS]: Checkout reliability release due Oct 2, promised to the COO after three incidents; 16 engineering days and 4 design days remain. EU consent remediation due Oct 9 for a contractual commitment; 12 engineering days, 3 design days, and 2 analyst days remain. Team also spends about 5 engineering days per two-week sprint on support. Current date is Sep 18. [NEW_REQUESTS]: Sales asks for enterprise SSO by Oct 6 for a prospect they value at $180k ARR; estimate is 14 engineering days and 2 design days, pending architecture review. Marketing asks for referral tracking by Sep 30 for a paid campaign; estimate is 6 engineering days and 2 analyst days. [CAPACITY_EVIDENCE]: Through Oct 9, Engineering has 42 planned person-days before support; design has 10 days; analyst has 4 days. One engineer is on call throughout the first week. No overtime is approved. Estimates are from team leads except SSO, which is preliminary. [DECISION_CONTEXT]: VP says all four are top priority. COO will not accept another checkout slip. Legal says the EU date is contractual. Marketing can move media spend once with five business days' notice. Sales has not confirmed whether the prospect would accept a phased SSO pilot.
Example output
# Priority Exchange Gate ## 1. Capacity verdict **Label: evidenced conflict.** Checkout reliability, EU consent remediation, enterprise SSO, referral tracking, and recurring support compete for the same engineering capacity; the four dated initiatives alone total **48 estimated engineering days against 42 planned engineering person-days through Oct 9, before support**, so all four cannot be protected as currently requested without an exchange. The decisive evidence is the 48-versus-42 engineering comparison before recurring support is counted; the weakest assumption is the preliminary **14-day SSO estimate**, with additional uncertainty over the exact support load in this window and whether first-week on-call impact is already reflected in the 42-day capacity figure. ## 2. Commitment ledger ### Already committed | Commitment | Owner / requester | Promised outcome | Deadline | Remaining effort / evidence | Scarce resource / dependency | Current status | Consequence of reduction or delay | Confidence | | ---------------------------- | -------------------------------------------- | --------------------------------------------- | --------------------------------------------------- | -------------------------------------------------- | ----------------------------------- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | Checkout reliability release | COO commitment; product/engineering delivery | Reliability release following three incidents | **Oct 2 — fixed**; COO will not accept another slip | 16 engineering days; 4 design days | Engineering, design | Already committed; work remains | Delay creates another checkout slip contrary to COO constraint. Scope/quality reduction consequences are not supplied. | Estimates stated by team leads | | EU consent remediation | Legal / contractual commitment | Complete consent remediation | **Oct 9 — fixed** | 12 engineering days; 3 design days; 2 analyst days | Engineering, design, shared analyst | Already committed; work remains | Delay misses a contractual date. Specific contractual consequences are not supplied. | Estimates stated by team leads | ### New requests | Commitment | Owner / requester | Promised outcome | Deadline | Remaining effort / evidence | Scarce resource / dependency | Current status | Consequence of reduction or delay | Confidence | | ----------------- | ----------------- | ---------------------------------------------------------- | --------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | Enterprise SSO | Sales | Enterprise SSO for a prospect valued by Sales at $180k ARR | **Oct 6 — preferred/requested, not established as fixed** | Preliminary 14 engineering days; 2 design days | Engineering, design; architecture review; prospect acceptance of any phased pilot | New request; architecture review pending | Full-delay effect on the prospect is unknown. Sales has not confirmed whether a phased pilot is acceptable. | **Estimated/preliminary** | | Referral tracking | Marketing | Referral tracking for paid campaign | **Sep 30 — preferred/changeable** | 6 engineering days; 2 analyst days | Engineering, shared analyst; campaign timing | New request | Marketing would need to move media spend; it can do so once with five business days' notice. Other impact is not supplied. | Estimates stated by team leads | ### Recurring obligation | Commitment | Owner / requester | Promised outcome | Deadline | Remaining effort / evidence | Scarce resource / dependency | Current status | Consequence of reduction or delay | Confidence | | ------------------- | ------------------------ | ------------------------- | --------- | -------------------------------------------- | ---------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------ | | Engineering support | Existing team obligation | Maintain support coverage | Recurring | About 5 engineering days per two-week sprint | Engineering | Ongoing | Consequence of removing or reducing support is not supplied, so it should not be treated as free capacity. | Estimated recurring load | ## 3. Capacity evidence check **Comparison basis:** person-days through Oct 9. Engineering, design, and analyst capacity can each be compared with workload stated in the same unit, but recurring support cannot be converted into an exact amount for this window without knowing the applicable sprint overlap or expected support days through Oct 9. | Resource | Evidenced capacity | Evidenced dated initiative load | What the evidence shows | | ----------- | ----------------------------------------: | --------------------------------------------: | -------------------------------------------------------------------- | | Engineering | 42 planned person-days **before support** | 48 estimated days across all four initiatives | **6-day shortfall before support is counted** | | Design | 10 days | 9 estimated days | 1 nominal day remains; no other design interruptions are supplied | | Analyst | 4 days | 4 estimated days | Fully allocated if EU remediation and referral tracking both proceed | **Protected obligations:** checkout reliability because another slip is explicitly unacceptable to the COO; EU consent remediation because Oct 9 is contractual; recurring support because it is an existing obligation and no authority to remove it has been supplied. **Known interruptions:** about 5 engineering days of support per two-week sprint and one engineer on call throughout the first week. The evidence does not state whether the on-call effect is already included in the 42 planned engineering days. **Evidenced load:** 28 engineering days for the two existing dated commitments; 20 additional estimated engineering days for SSO and referral tracking; 9 design days if SSO is added; 4 analyst days if referral is added. **Uncounted load:** exact support consumption through Oct 9; any capacity loss caused by first-week on-call if not already reflected in the 42 days; architecture-review effort if separate from the SSO estimate. **Material assumptions:** SSO remains near its preliminary 14-day estimate; team-lead estimates for the other initiatives remain representative; the 42 planned engineering days are genuinely available apart from support; no additional qualified capacity is already committed. **Smallest additional measurement needed:** confirm the engineering days expected to be consumed by support through Oct 9 and whether on-call is already deducted from the 42 planned days. This determines the usable engineering headroom after protected work. ## 4. Priority collision map | Type | Commitments competing | Shared bottleneck | Constraints that cannot coexist as stated | Earliest failure signal | Resolution authority | | ------------------------------------------------------ | ------------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | **Hard capacity collision** | Checkout + EU + full SSO + referral + support | Engineering | The four dated initiatives require 48 estimated engineering days against 42 before support; retaining support increases the gap | Already visible in the portfolio plan: estimated demand exceeds gross planned capacity | **VP Product** for roadmap exchange; Engineering for any staffing solution | | **Unclear estimate, not a separate capacity solution** | SSO versus remaining portfolio capacity | Engineering | SSO is being treated as an Oct 6 priority before architecture review has validated its 14-day estimate or a smaller pilot | Architecture review materially changes the estimate or confirms it | VP Product for scope/priority; Engineering for staffing | | **Preference dispute** | “All four are top priority” versus differentiated constraints | Engineering and analyst capacity | A priority label cannot protect four requests when one legal date and one COO commitment are fixed and capacity is finite | Any request to start new work without naming what it displaces | VP Product | | **Coordination constraint** | Referral timing versus any decision to defer it | Marketing campaign schedule | Moving the campaign remains available only if Marketing receives five business days' notice | Five-business-day notice cutoff | VP Product for portfolio choice; Marketing for campaign rescheduling | The analyst allocation of 4 days against 4 days is zero-slack, but the supplied evidence does not establish a hard analyst collision. Design likewise does not show a hard collision on the supplied totals. ## 5. Exchange scenarios ### Scenario A — Protect checkout, EU, and referral; move full SSO **Protected:** Checkout by Oct 2, referral tracking by Sep 30, EU remediation by Oct 9, and recurring support. **Exchange:** Full enterprise SSO moves beyond Oct 9. Before then, SSO remains at architecture review/pilot-definition stage rather than becoming an assumed full delivery commitment. **Stakeholder impact:** Sales cannot promise full SSO for Oct 6 on current capacity. Marketing retains its campaign timing; COO and Legal constraints remain protected. **Reversibility:** High before full SSO implementation begins. A smaller SSO pilot could be reconsidered if Sales confirms it is acceptable and architecture review demonstrates that it fits verified residual capacity. **Assumptions:** Checkout, EU, and referral estimates hold; support plus any uncounted on-call impact fits within the **8 engineering days of gross headroom** left after those three initiatives, or an exchange is reopened. **Decision deadline:** **(date needed)**, before SSO is treated as an Oct 6 delivery commitment. ### Scenario B — Protect checkout and EU; trade referral timing for a smaller SSO pilot **Protected:** Checkout, EU remediation, recurring support, and only a specifically scoped SSO pilot—not the current unvalidated full SSO request. **Exchange:** Marketing moves its media spend once, using the available five-business-day notice mechanism. The 6 engineering days and 2 analyst days for referral tracking are released from the current window. **Stakeholder impact:** Marketing's campaign moves. Sales receives a chance to protect the prospect requirement, but only if the prospect accepts a phased pilot and architecture review produces a scope that fits the residual capacity. **Reversibility:** Moderate. Marketing can move spend once; once that option is used, reversing the decision may not be harmless. **Assumptions:** Sales confirms a pilot is acceptable; architecture review produces a materially smaller SSO scope; the resulting engineering load fits after checkout, EU, and support. **Decision deadline:** Before Marketing's five-business-day notice cutoff and before Sales makes an Oct 6 commitment. ### Scenario C — Protect all four by adding confirmed qualified capacity **Protected:** All four dated initiatives. **Exchange:** Engineering adds or transfers qualified capacity rather than displacing a roadmap item. The required increment is **at least 6 engineering days plus the support load through Oct 9 and any on-call reduction not already included in the 42-day capacity figure**. **Stakeholder impact:** The displacement occurs in Engineering's broader staffing portfolio rather than within these four initiatives; the affected work is unknown until Engineering names it. **Reversibility:** Low to moderate once people are reassigned and work is started. **Assumptions:** Engineering has qualified capacity that can contribute in time without creating an unacknowledged collision elsewhere. No such capacity has yet been confirmed. **Decision deadline:** **(date needed)**, before staffing and campaign decisions become harder to reverse. ## 6. Recommended exchange **Choose Scenario A: protect checkout reliability, EU remediation, referral tracking, and recurring support, and move full enterprise SSO beyond Oct 9 unless a prospect-accepted pilot is subsequently shown to fit verified residual capacity.** This protects the two strongest supplied constraints—the COO's no-slip checkout commitment and the contractual EU date—while preserving the referral request that can fit within the gross plan if support and on-call consume no more than the remaining engineering headroom. The cost falls primarily on Sales and the SSO request, which is proportionate because SSO is a new request with a preliminary estimate, its architecture review is incomplete, and the prospect's willingness to accept a phased option is still unknown. Moving referral instead would not, by itself, make full SSO feasible: checkout, EU, and the preliminary SSO estimate already consume all 42 gross engineering days, leaving no capacity for support. ## 7. Decision request **Decision owner:** VP Product **Decision needed:** Which named work will be exchanged for the requested SSO priority, given that all four dated initiatives cannot fit within current engineering capacity. **Recommended option:** Scenario A — keep checkout, EU, referral, and support protected; move full SSO beyond Oct 9 unless a smaller validated pilot fits. **Alternatives declined:** Full SSO plus referral with current staffing, because estimated engineering demand already exceeds planned capacity before support; Scenario B unless Sales confirms pilot acceptance and architecture validates a smaller scope; Scenario C unless Engineering confirms qualified additional capacity and names the work it displaces. **Answer by:** **(date needed)**; any choice that moves referral must also be made before Marketing's five-business-day notice cutoff. **Default if no answer:** No legitimate default has been authorized. While waiting, it is safe to continue the already committed checkout and EU work and recurring support; new work should not be treated as authorized displacement merely because it is labelled “top priority.” **Immediate action after decision:** Product records the exchange, Engineering assigns capacity against the chosen queue, and the affected stakeholder is told exactly which commitment moved or changed. ## 8. Escalation message VP Product — the shared goal for this window is to protect the outcomes we have committed while making the new priorities explicit enough for Engineering to staff them. Through Oct 9 we have 42 planned engineering person-days before support. Checkout and EU remediation require 28 estimated days; adding referral and the preliminary SSO estimate brings the dated work to 48 days before support, so all four cannot remain protected as currently requested. I recommend keeping checkout, EU remediation, referral tracking, and support protected, and moving full SSO beyond Oct 9 unless the architecture review produces a smaller pilot that Sales confirms the prospect will accept and that fits verified remaining capacity. Moving referral alone would not make the current full SSO estimate fit because checkout + EU + SSO already use the full 42 planned engineering days before support. Please decide whether to approve that exchange or name the specific commitment, scope, staffing, or deadline that should move instead. For any option that moves referral, we also need to preserve Marketing's five-business-day notice window. ## 9. Meeting talk track and working queue ### 60-second spoken version We have a capacity decision, not four simultaneously executable “top priorities.” Through Oct 9, Engineering has 42 planned person-days before support. Checkout needs 16, EU remediation 12, referral 6, and SSO is preliminarily 14, for 48 before we count recurring support. Checkout's Oct 2 date is protected by the COO constraint, and EU's Oct 9 date is contractual. Moving referral would free six days, but checkout, EU, and the current SSO estimate would still consume all 42 days before support, so that does not solve the problem by itself. My recommendation is to protect checkout, EU, referral, and support, and move full SSO beyond Oct 9 unless architecture produces a smaller pilot that Sales confirms the prospect will accept and that fits verified capacity. If SSO must stay, we need the meeting to name exactly what it displaces or Engineering must confirm qualified added capacity. ### Likely objections **“They're all top priority; Engineering should parallelize them.”** Parallel execution changes sequencing, not total capacity. The four initiatives require 48 estimated engineering days against 42 planned days before recurring support. The collision remains regardless of how the work is arranged across four engineers. **“Move referral and use those days for SSO.”** Moving referral releases 6 estimated engineering days, but checkout + EU + preliminary SSO already total 42—the entire gross engineering capacity through Oct 9. That leaves no room for the existing support obligation, so full SSO still requires a smaller scope or added capacity. **“The SSO prospect is worth $180k ARR, so it has to fit.”** The prospect value can justify an exchange, but it does not create capacity. If VP Product chooses to protect SSO, the decision must also name the work that moves, reduce SSO to a prospect-accepted pilot, or obtain confirmed qualified capacity from Engineering. ### Working queue if the recommendation is accepted 1. **Checkout reliability — protected Oct 2 commitment.** 2. **Referral tracking — retain Sep 30 delivery only within capacity that does not jeopardize checkout, EU, or recurring support.** 3. **EU consent remediation — protected Oct 9 contractual commitment.** 4. **Recurring engineering support — continue as an explicit capacity claim, not hidden overhead.** 5. **Enterprise SSO — architecture review and pilot validation only; full implementation moves beyond Oct 9 unless a smaller accepted scope is proven to fit or qualified capacity is explicitly added.** Engineering may execute the protected items in parallel according to its staffing plan; this queue defines which commitments may displace others, not an invented engineer-by-engineer schedule. **Decision record:** VP Product decided on **[chosen exchange]** on **[date]**; **[named commitment/scope/deadline/staffing change]** is the explicit displacement required to protect **[protected priority]**.
GPT

Capacity Conflict Escalation Brief

Add to Cart
PromptBase Select
Get this prompt + 9 more with Select$14 your first month, then $19/mo$14 first month, then $19/mo
View Select
Instant accessInstant access
Usage rightsCommercial use
Money-back guaranteeMoney‑back
By purchasing this prompt, you agree to our terms of service
GPT-5.6
Tested icon
Guide icon
4 examples icon
Free credits icon
Turn an impossible workload into a decision leaders can actually make—not a vague complaint about being busy. Get a commitment ledger, capacity evidence check, priority collisions, one-in/one-out trade-off scenarios, impact comparison, a single recommendation, and a concise escalation message. Built for employees, managers, project leads, and product teams facing multiple “top priorities.” Tested on ChatGPT gpt-5.6.
...more
Added over 1 month ago
Report
Browse Marketplace