Tasks / Product Craft

Make the launch call

Can the model make a clear go / no-go call from mixed launch evidence, checked against the criteria agreed up front?

Task type v1.2 · 2 tasksLast changed 6 Oct 2026 · ChangelogDifficulty

What AI gets right here, and what you’ll still have to catch

From 18 graded outputs by 9 models. 67% were usable with at most a quick edit.

Reliably right

  1. Produces the required deliverable100% pass
    Provides a complete recommendation with table, reasoning, email plan, and next steps, usable by a product manager with light edits.
    Sonnet 5.5 · API · Offline, on older phones
  2. Finds the Scotland breach100% pass
    Finds Scotland's refund breach, ties it to the supplier change, notes the acceptance dip, and holds Scotland.
    GPT-6.1 Sol · API · Go/no-go for AI substitutions, from the rollout data
  3. Treats the overwrites as data loss100% pass
    Treats the Android 11 overwrites as a breach of the no-data-loss criterion and makes a fix a condition for that platform.
    Sonnet 5.5 · API · Offline, on older phones

Where it slips

  1. Judges the launch against a baseline set now51% pass
    Does not name a specific review point or when the team will review results to decide next steps; only gives a pause trigger without a scheduled evaluation.
    GPT-6.1 Sol · API · Offline, on older phones
  2. Checks every criterion for every platform64% pass
    Android 13's error-free sync is 98.9%, below the 99% threshold, yet the table marks it as 'GO WITH CONDITIONS' instead of 'NO-GO' for that criterion, misapplying the hard launch criteria.
    Gemini 3.5 Flash-Lite · Gemini · Offline, on older phones
  3. Gets the base of every number right67% pass
    The 80.5% user base proportion is miscalculated; correct proportion from the data is 79.5%.
    Gemini 4 Argon · API · Offline, on older phones

How it’s graded

Each check is built on how world-class product and growth leaders do this work, as they’ve described it on Lenny’s Podcast, and names the leader it comes from.

  1. Limits the downside of being wrong

    Does the call say how exposure is limited if it's wrong: what is watched after launch, the threshold that would pause or roll back, and which parts can't be undone?

    Passes when Names the post-launch signal, a threshold or trigger, and the action, and flags anything irreversible (customer communications, pricing, migrations).

  2. Judges the launch against a baseline set now

    Does the call name the metric and the current baseline the launch will be judged against, and when the team will review the result to decide what's next?

    Passes when Names the success metric, its baseline from the material, and a review point with what each result would lead to.

Plus our standard checks

Uses the supplied evidence correctly · Addresses the actual decision · Respects explicit constraints · Identifies material uncertainty · Avoids unsupported claims · Produces the required deliverable · Gets the base of every number right · and 2 written for each task, which you’ll see in the tasks below.

The tasks

Read the brief, then compare up to three outputs, each with the LLM judge’s verdict on every check. Highlights mark what a PM had to fix.

The brief

You're the PM for Lumen's mobile apps. The launch review for offline sync is on Friday, and marketing has an email booked for Monday to every user. Write your recommendation, in no more than 700 words, with a table checking each launch criterion for each platform: go, no-go or go with conditions, and why. The rollout data, the criteria and the incident log are attached.

What the model was given5 items: About Lumen, launch_criteria.md, rollout_25pct_14_days.csv, incidents.md, the_decision.md
About LumenA notes app for teams, on iOS, Android and the web. Offline sync lets people edit notes without a connection and merges changes when they reconnect.
launch_criteria.md6 lines · Download
# Launch criteria (agreed before the rollout)

1. Crash-free sessions no more than 0.2 points below control, per platform.
2. Sync-conflict tickets under 2 per 1,000 users.
3. Notes synced without error at least 99%.
4. No data loss incidents.
rollout_25pct_14_days.csv8 rows · Download
platform,arm,users,crash_free_sessions_pct,sync_conflict_tickets_per_1000_users,notes_synced_without_error_pct
iOS 17+,control,123600,99.62,0.3,99.5
iOS 17+,offline sync,41200,99.58,0.6,99.4
Android 14+,control,68400,99.55,0.3,99.5
Android 14+,offline sync,22800,99.49,0.8,99.2
Android 13,control,27300,99.4,0.3,99.5
Android 13,offline sync,9100,99.31,1.1,98.9
…
incidents.md4 lines · Download
# Incidents during the 25% rollout (14 days)

- 2 reports of a note's edits being overwritten after a conflict, both on Android 11; engineering recovered both from backups. Root cause: an older Android storage API.
- 1 report of slow sync on iOS, not reproduced.
the_decision.md1 lines · Download
The launch review is Friday: roll offline sync out to 100%, or not. Marketing has a launch email booked for Monday to every user.
What a strong answer doesThe answer key the graders mark against

Checks each criterion per platform. iOS 17+, Android 14+ and Android 13 pass: crash-free sessions within 0.2 points of control (iOS -0.04, Android 14+ -0.06, Android 13 -0.09), sync-conflict tickets under 2 per 1,000, notes synced without error at least 99%. Android 12 and older fails three criteria: crash-free down 0.67 points against control, 4.9 conflict tickets per 1,000, 96.1% synced without error; and the two overwritten-note incidents were on Android 11, which breaks 'no data loss' (both recovered from backup, root cause an older storage API). Recommends go for iOS, Android 13 and newer, and no-go for Android 12 and older until the storage issue is fixed and re-tested; the Monday email should only go to users on supported versions, or wait. States what's monitored after launch and the threshold that would pause it.

Critical failures (cap the score at 40)
  • Recommends rolling out to 100% on every platform
Task

Staff-level · v1.1

The outputs

9 setups answered this brief.

Usable with a quick edit7 of 11 checks passed

The platform decisions and table are correct; a PM could quickly fix the 80.5% arithmetic and add a monitoring plan without redoing the analysis.

Output

To: Launch Review Committee From: Product Manager, Mobile Apps Date: Friday (Launch Review) Subject: Offline Sync 100% Rollout Recommendation

Executive Recommendation: Go with Conditions (Segmented Rollout)

Based on our 14-day, 25% rollout data, I recommend a Go for iOS 17+ and Android 14+, which represent 80.5% of our mobile user base.

I recommend a No-Go for Android 12 and older due to severe stability and data loss issues, and a Go with Conditions (or short delay) for Android 13, which narrowly missed our sync error threshold by 0.1%.

Consequently, Marketing must not send the Monday launch email to every user. We must either segment the email to eligible OS versions or adjust the messaging to reflect system requirements (iOS 17+ / Android 14+).

---

Launch Criteria Evaluation by Platform

Platform (% of Total Users)1. Crash-Free Sessions (Max -0.2 pts vs. Control)2. Conflict Tickets (< 2.0 per 1k users)3. Sync Success Rate (≥ 99.0%)4. Data Loss Incidents (0 incidents)Decision & Rationale
:---:---:---:---:---:---
iOS 17+<br>(51.2%)PASS<br>99.58% vs 99.62%<br>(-0.04 pts)PASS<br>0.6PASS<br>99.4%PASS<br>0 incidents (1 unrep. slow sync)GO<br>Meets all criteria comfortably.
Android 14+<br>(29.3%)PASS<br>99.49% vs 99.55%<br>(-0.06 pts)PASS<br>0.8PASS<br>99.2%PASS<br>0 incidentsGO<br>Meets all criteria comfortably.
Android 13<br>(11.7%)PASS<br>99.31% vs 99.40%<br>(-0.09 pts)PASS<br>1.1FAIL<br>98.9%<br>(-0.1% below target)PASS<br>0 incidentsGO WITH CONDITIONS<br>Borderline miss on sync errors (98.9%). Safe on data loss and crashes.
Android 12 & older<br>(9.5%)FAIL<br>98.71% vs 99.38%<br>(-0.67 pts)FAIL<br>4.9FAIL<br>96.1%FAIL<br>2 overwritten notes on Android 11NO-GO<br>Fails every criterion. Legacy storage API causes data overwrites.

---

Detailed Rationale & Next Steps

1. Greenlight iOS 17+ and Android 14+ (Roll out to 100% on Monday) Both modern platforms passed every gate with healthy margins. The single report of slow sync on iOS could not be reproduced and did not impact overall sync success rates (99.4%). These cohorts are ready for a 100% rollout.

2. Block & Roll Back Android 12 and Older (Immediate Action) Android 12 and older failed all four launch criteria. Most critically, an older Android storage API caused two incidents on Android 11 where conflict resolution overwrote user edits (requiring manual backup recovery by engineering). For a collaborative notes app, data loss is a dealbreaker. * Action: Immediately roll back the 25% test cohort on Android ≤12 to 0%. Engineering will scope whether fixing the legacy storage API is worth the investment for 9.5% of our base, or if we officially deprecate offline sync for Android ≤12.

3. Android 13 Conditions Android 13 passed stability, conflict ticket, and zero-data-loss criteria, but hit 98.9% on error-free syncs (0.1 points short of our 99.0% gate). * Condition for Go: If Engineering confirms before EOD today that Android 13 does not use the legacy storage API that caused the Android 11 data loss, and that the 1.1% error rate fails gracefully (i.e., retries on next connection without corrupting data), we can include Android 13 in Monday’s launch while fast-following a patch. * Alternative: If there is any architectural overlap with the Android 11 bug, hold Android 13 at 25% until patched.

4. Marketing & Monday Email Plan Because we are holding back at least 9.5% (and up to 21.2%) of users on older Android versions, we cannot send a blanket announcement to all users without generating support tickets and frustration. Marketing has two options for Monday: * Option A (Recommended): Segment the email list to send only to users on iOS 17+ and Android 14+ (and Android 13, if cleared today), plus Web users. * Option B: Send to all users, but explicitly state in the email body and help docs: "Offline sync is rolling out today for iOS 17+ and Android 14+."

Claims the judge couldn’t find in the brief

  • iOS 17+ and Android 14+ represent 80.5% of our mobile user base.

Grades and run details

Decision model 73 · LLM judge 67
Decision model checks
  • passUses the supplied evidence correctly23%
  • passAddresses the actual decision62%
  • passRespects explicit constraints43%
  • passIdentifies material uncertainty97%
  • partialAvoids unsupported claims25%
  • passProduces the required deliverable61%
  • partialChecks every criterion for every platform52%
  • passTreats the overwrites as data loss100%
  • partialLimits the downside of being wrong70%
  • failGets the base of every number right13%
  • partialJudges the launch against a baseline set now30%
Run
Run
#1
API response time
12 s
Submitted
13 Oct 2026

Usable with a quick edit10 of 11 checks passed

The output is clear, complete, and actionable; the missing explicit review point is a small omission that a PM could add with a quick edit without rechecking evidence or redoing reasoning.

Output

Recommendation for Friday

No-go for a blanket 100% launch. Approve a platform-gated launch for iOS 17+ and Android 14+, provided eligibility can be enforced reliably. Hold Android 13, stop expansion on Android 12 and older, and do not launch on untested platforms.

Replace Monday’s all-user email with a targeted announcement to eligible users only. If targeting or platform gating cannot be verified before send time, postpone the email.

Launch-criteria assessment

Crash-free changes below are percentage-point differences versus each platform’s control. The agreed limit is a decline of no more than 0.20 points.

PlatformCrash-free sessionsConflict tickets: <2/1,000Notes synced without error: ≥99%No data loss incidentsPlatform decision
iOS 17+Go: 99.58%; −0.04 pointsGo: 0.6Go: 99.4%Go: none reportedGo with conditions: passes all measured criteria; launch with eligibility gating and monitoring.
Android 14+Go: 99.49%; −0.06 pointsGo: 0.8Go: 99.2%Go: none reportedGo with conditions: passes all measured criteria; launch with eligibility gating and monitoring.
Android 13Go: 99.31%; −0.09 pointsGo: 1.1No-go: 98.9%, below the 99% minimumGo: none reportedNo-go: sync reliability misses the agreed threshold.
Android 12 and olderNo-go: 98.71%; −0.67 pointsNo-go: 4.9No-go: 96.1%No-go: two overwrite incidents on Android 11No-go: fails all four criteria.
Web / iOS below 17, if supportedNo-go: no evidence suppliedNo-go: no evidence suppliedNo-go: no evidence suppliedNo-go: not established by supplied evidenceNo-go pending validation: absence of rollout data is not a pass.

The recovered Android 11 edits still count as data-loss incidents for this launch gate: users’ edits were overwritten, and recovery required backups. Recovery mitigated the harm; it does not erase the incidents. Nor should Android 11’s identified root cause be used to clear the rest of the “Android 12 and older” cohort without separate evidence.

Conditions and next steps

  • Before expanding eligible cohorts: Engineering must verify OS-level gating, rollback controls, and platform-specific monitoring. Increase exposure in monitored steps toward 100% of eligible users, pausing if a launch criterion is breached. Investigate the unreproduced iOS slow-sync report; it is not currently evidence of a failed criterion.
  • Android 13: Diagnose the sync-error shortfall, ship a fix, and repeat validation against the same ≥99% threshold. Do not round 98.9% up or waive the criterion to meet the email date.
  • Android 12 and older: Halt expansion and safely disable affected functionality where feasible, preserving pending offline edits before any rollback. Fix the older-storage-API issue, test conflict recovery and data integrity, and rerun a controlled rollout demonstrating all four criteria.
  • Marketing and support: Clearly state supported versions and avoid implying universal availability. Give support a recovery and escalation playbook.

These results cover 14 days at 25% exposure, not proof of risk-free operation at full scale. The defensible decision is a constrained launch where the evidence passes—not a universal launch driven by Monday’s booking.

Grades and run details

Decision model 91 · LLM judge 92
Decision model checks
  • passUses the supplied evidence correctly61%
  • passAddresses the actual decision85%
  • passRespects explicit constraints58%
  • passIdentifies material uncertainty100%
  • passAvoids unsupported claims49%
  • passProduces the required deliverable85%
  • partialChecks every criterion for every platform48%
  • passTreats the overwrites as data loss100%
  • passLimits the downside of being wrong97%
  • passGets the base of every number right91%
  • partialJudges the launch against a baseline set now30%
Run
Run
#1
Time to output
16 s
Submitted
5 Oct 2026

Needs more than a quick edit8 of 11 checks passed

Missing a post-launch monitoring plan with thresholds and a baseline for success, which a PM would need to add before acting.

Output

Recommendation

Do not roll offline sync out to every user or send Monday’s email to every user as a general launch announcement. The agreed criteria are not met on Android 13 or Android 12 and older, and the Android 11 overwrite reports fail the no-data-loss gate even though the notes were recovered from backups.

Approve rollout to 100% only for iOS 17+ and Android 14+, where all four criteria pass. Keep Android 13 and older gated until they meet the criteria and the Android 11 storage issue is fixed and validated. Change Monday’s email to target eligible users, or postpone it; don’t imply the feature is available to everyone. Monitor the unreproduced iOS slow-sync report.

Platform / cohortDecisionCrash-free sessionsConflict ticketsNotes synced without errorNo data loss
iOS 17+GoGo — 0.04 percentage points below control; within 0.2.Go — 0.6/1,000; under 2.Go — 99.4%; at least 99%.Go — no data-loss incident reported.
Android 14+GoGo — 0.06 points below control; within 0.2.Go — 0.8/1,000; under 2.Go — 99.2%; at least 99%.Go — no data-loss incident reported.
Android 13Go with conditions — hold rollout until notes-sync criterion passes.Go — 0.09 points below control; within 0.2.Go — 1.1/1,000; under 2.No-go — 98.9%; below 99%.Go — no data-loss incident reported.
Android 12 and olderNo-go — keep blocked; investigate and validate by OS version.No-go — 0.67 points below control; exceeds 0.2.No-go — 4.9/1,000; exceeds 2.No-go — 96.1%; below 99%.No-go — the cohort includes Android 11, where two overwritten edits were reported. Recovery does not erase the incident.

The Android 12-and-older metrics are grouped, so they do not establish that each OS version performs equally; assess Android 12 separately before reconsidering it.

Grades and run details

Decision model 82 · LLM judge 75
Decision model checks
  • passUses the supplied evidence correctly80%
  • passAddresses the actual decision83%
  • passRespects explicit constraints74%
  • passIdentifies material uncertainty92%
  • passAvoids unsupported claims51%
  • passProduces the required deliverable79%
  • failChecks every criterion for every platform25%
  • passTreats the overwrites as data loss100%
  • partialLimits the downside of being wrong91%
  • passGets the base of every number right82%
  • partialJudges the launch against a baseline set now37%
Run
Run
#1
API response time
21 s
Submitted
6 Oct 2026

Check by check

Where the outputs differ comes first. Open a check to read the judge’s reasons. “Mixed” means the two graders disagreed.

Where they differ 4

Uses the supplied evidence correctlyMixedRightRight
Gemini 4 Argon · API

The claim that iOS 17+ and Android 14+ represent 80.5% of mobile users is incorrect; the correct proportion from the supplied data is 79.5%.

GPT-6 Astra · ChatGPT

All factual claims about the current situation are taken directly from the supplied rollout data, incidents log, and launch criteria, with no invented numbers or events.

GPT-6 Luna · API

All facts and figures are taken correctly from the supplied context, with no invented information.

Checks every criterion for every platformRightRightMixed
Gemini 4 Argon · API

Table correctly computes each criterion per platform, identifying Android 12 and older as the only failing platform across all criteria.

GPT-6 Astra · ChatGPT

The table correctly computes each criterion for every platform against its control and threshold, and correctly identifies Android 12 and older as failing (and Android 13 as failing the sync-error criterion).

GPT-6 Luna · API

The table correctly computes each criterion for each platform against control and thresholds, and correctly identifies Android 12 and older as failing.

Limits the downside of being wrongWrongRightWrong
Gemini 4 Argon · API

Does not name a post-launch monitoring signal, threshold, or action for the greenlit platforms, nor flag irreversible customer communications beyond email segmentation.

GPT-6 Astra · ChatGPT

It names the post-launch signal (launch criteria), the threshold (breach of any criterion), the action (pause), and flags the irreversible email by recommending targeting or postponement.

GPT-6 Luna · API

Does not name a post-launch signal, threshold, or action to pause or roll back for the platforms going live, nor flag anything irreversible.

Gets the base of every number rightWrongRightRight
Gemini 4 Argon · API

The 80.5% user base proportion is miscalculated; correct proportion from the data is 79.5%.

GPT-6 Astra · ChatGPT

All percentage-point differences are computed correctly from the control and offline-sync values, and the base (percentage points vs control) is stated clearly.

GPT-6 Luna · API

All derived differences and percentages are computed correctly from the supplied data, and bases are clear.

All got wrong 1

Judges the launch against a baseline set nowWrongWrongWrong
Gemini 4 Argon · API

Does not name a post-launch review timeline or baseline metric beyond the existing launch criteria, nor what each result would lead to.

GPT-6 Astra · ChatGPT

The output does not name a specific success metric with its baseline from the material, nor a scheduled review point with what each result would lead to; it only mentions pausing on breach without a defined review cadence.

GPT-6 Luna · API

Does not name a success metric, its current baseline, or a review point with what each result would lead to.

All got right 6

Addresses the actual decisionRightRightRight
Gemini 4 Argon · API

Commits to a clear per-platform recommendation (Go/No-Go/Go with Conditions) early, and states what would change for Android 13.

GPT-6 Astra · ChatGPT

The output commits early to a clear call (no blanket launch, platform-gated go for iOS 17+ and Android 14+, hold Android 13, stop Android 12 and older) and states what would change it (gating verification, fix and re-validation).

GPT-6 Luna · API

Commits to a clear answer (rollout only to iOS 17+ and Android 14+, gate others, change email) and states conditions that would change it.

Respects explicit constraintsRightRightRight
Gemini 4 Argon · API

The recommendation is within 700 words, contains the required table, and addresses a launch review committee.

GPT-6 Astra · ChatGPT

The output is a recommendation under 700 words, includes the required table with go/no-go/go with conditions per platform, and addresses the launch review decision.

GPT-6 Luna · API

Respects the 700-word limit, includes the required table with go/no-go per platform and criterion, and addresses the Monday email.

Identifies material uncertaintyRightRightRight
Gemini 4 Argon · API

Identifies key uncertainty about Android 13's storage API overlap and defines the condition for inclusion.

GPT-6 Astra · ChatGPT

It names the unreproduced iOS slow-sync report, the need to verify platform gating, and the Android 13 sync-error shortfall as unknowns, and says how each would be resolved or would change the call.

GPT-6 Luna · API

Names the grouped Android 12-and-older data as an unknown and says to assess Android 12 separately; also flags the unreproduced iOS slow-sync report to monitor.

Avoids unsupported claimsRightRightRight
Gemini 4 Argon · API

No interpretations or causes are presented as established fact beyond what's supported; the root cause is from the incident log.

GPT-6 Astra · ChatGPT

Interpretations (e.g., the overwrites counting as data loss) are clearly presented as judgments based on the criteria, not as established facts, and no unsupported causal claims are made.

GPT-6 Luna · API

No interpretations or forecasts are presented as established fact; the recovery-not-erasing-incident statement is a correct application of the criterion.

Produces the required deliverableRightRightRight
Gemini 4 Argon · API

The memo includes the table, clear calls per platform, and actionable steps for marketing, making it immediately usable.

GPT-6 Astra · ChatGPT

The output is a complete recommendation with a table, within the word limit, and a PM could act on it with only light edits.

GPT-6 Luna · API

The recommendation is complete, in the right form for a launch review, within the word limit, and usable with light edits.

Treats the overwrites as data lossRightRightRight
Gemini 4 Argon · API

Treats the overwritten notes as a data-loss incident and uses it as a reason for no-go for Android 12 and older.

GPT-6 Astra · ChatGPT

The output explicitly treats the Android 11 overwrites as a breach of the no-data-loss criterion and makes fixing the storage-API issue a condition for that platform.

GPT-6 Luna · API

Treats the Android 11 overwrites as a breach of the no-data-loss criterion and makes fixing the storage issue a condition for that platform.

Results

Every setup we’ve tested on this task type, across all its tasks and repeats, graded on the current checklist. Calibrated. Where our PM checked the graders by hand, they agreed on 62% of 68 checks.

#Model · HarnessTask scoreDecision modelLLM judgeRunsCritical failures
1Sonnet 5.5withAPI92.4100.02None
2GPT-6.1 SolwithAPI91.995.82None
3Haiku 5.5withAPI84.3100.02None
4GPT-6 AstrawithChatGPT91.992.52None
5Opus 5.5withClaude84.396.72None
6GPT-6 LunawithAPI80.280.82None
7Gemini 4 ArgonwithAPI70.373.32None
8Gemini 3.5 Flash-LitewithGemini55.059.22None
9Gemini 3.8 FlashwithAPI64.467.521 capped

What you get for the cost

Haiku 5.5 · API scores within 3 points of Sonnet 5.5 · API at about a tenth of the cost.

Task score against relative cost for each setup. The table below has the same figures.4050607080901001×3×10×30×Cost per output, relative to the cheapest setup (log scale) →↑ Task scoreSonnet 5.5 · API: task score 96, 37× the cheapestGPT-6.1 Sol · API: task score 94, 12× the cheapestHaiku 5.5 · API: task score 93, 2.8× the cheapestGPT-6 Astra · ChatGPT: task score 93, 46× the cheapest (1 of 2 outputs estimated)Opus 5.5 · Claude: task score 91, 59× the cheapest (1 of 2 outputs estimated)GPT-6 Luna · API: task score 79, the cheapestGemini 4 Argon · API: task score 71, 14× the cheapestGemini 3.5 Flash-Lite · Gemini: task score 55, 2.7× the cheapest (1 of 2 outputs estimated)Gemini 3.8 Flash · API: task score 54, 11× the cheapest, 1 critical failureSonnet 5.5 · APIGPT-6.1 Sol · APIHaiku 5.5 · APIGPT-6 Astra · ChatGPTOpus 5.5 · ClaudeGPT-6 Luna · APIGemini 4 Argon · APIGemini 3.5 Flash-Lite · GeminiGemini 3.8 Flash · API
Best valueNobody beats these on both score and costCost partly estimated (app runs with no usage meter)At least one critical failure
Task score and relative cost by setup
SetupTask scoreRelative cost (cheapest = 1)
GPT-6 Luna · API791.0×
Gemini 3.5 Flash-Lite · Gemini552.7× (partly estimated)
Haiku 5.5 · API932.8×
Gemini 3.8 Flash · API5411×
GPT-6.1 Sol · API9412×
Gemini 4 Argon · API7114×
Sonnet 5.5 · API9637×
GPT-6 Astra · ChatGPT9346× (partly estimated)
Opus 5.5 · Claude9159× (partly estimated)

Cost is each output’s tokens at the model’s list price, shown relative to the cheapest setup. Runs done in an app have no usage meter, so theirs are estimated from the same setup’s measured runs. How we compare cost

About the task

The PM job

Deciding whether a feature ships on the planned date, and on what conditions.

Why it matters

Launch meetings reward optimism. A good call checks each agreed criterion, weighs a real risk against a real gain, and says exactly what would change the answer. A weak one rubber-stamps the launch or blocks it on noise.

What good looks like

  • Checks each agreed criterion against the evidence
  • Makes one clear call, with conditions if needed
  • Separates risks that block launch from risks that can be managed
  • Says what would change the call
  • Says how to limit the damage if the call is wrong

Deliberately not measured

  • Rollout engineering detail
  • Project-plan formatting
Capability tested

Deciding against agreed launch criteria

The failure we’re looking for

Rubber-stamps a launch that misses an agreed bar, or blocks it on noise

Grading

Decision model and LLM judge, calibrated against a blind PM review

Variants

A launch memo from supplied evidence · Staff level: a regional call from an attached data workbook