Humanity’s Last PRD
Tasks / Operate

Write a stakeholder update

Can the model turn messy project status into an honest update that leads with what the reader needs to know or decide?

Measures the modelTask v1.0 · 2 casesDifficulty

The PM job

Writing the weekly update, or the reply to an executive's question, that the team's credibility rests on.

Why it matters

Updates are where bad news gets softened. A fluent update that buries a slipped date or presents a guess as the cause does more harm than no update: leadership decides on it, and trust goes when the truth comes out.

What good looks like

  • Leads with the news and any decision needed
  • States dates, numbers and causes plainly, including bad news
  • Separates what is known from what is suspected
  • Fits the reader and the length asked for

Deliberately not measured

  • Tone and formatting preferences
  • Writing style beyond clarity
Capability tested

Honest, decision-first status communication

The failure we’re looking for

Spin: burying or softening the bad news, or presenting a guess as fact

Grading

Decision model, LLM judge and blind PM review

Results

Every setup we’ve tested on this task, across all cases and repeats.

#Model · HarnessTask scoreDecision modelLLM judgePM reviewRunsCritical failuresCost / runLatency

Case viewer

Read the brief, then put up to three outputs side by side. The outputs are the point; the scores just tell you where to look.

The brief

You're the PM for bulk invoicing at Ledgerly. Using the material below, write this week's update to Dana Okafor, VP Product, who will forward it to the leadership team. Keep it under 250 words: she reads these on her phone.

ScenarioBulk invoicing lets customers send up to 500 invoices at once. Leadership was promised a launch on 12 October, and Marketing has booked a customer webinar for 14 October with 1,100 people registered.
Your update last week“On track for 12 October. Final QA starts next week.”
Team Slack this weekTom (engineering lead), Monday: “Payments told us on Friday they've pulled the batch-send API from their sprint; they're on the card-fraud incident. The earliest they can pick it up is the sprint starting 13 October.” Tom, Tuesday: “Without the batch API we can only send invoices one at a time. 500 invoices takes about 40 minutes and hits rate limits. Not shippable to the big accounts.” Aisha (design), Tuesday: “UI is done and tested with six customers, all positive.” Tom, Wednesday: “If Payments start on 13 October, a realistic launch is 26 October. 23 October if their sprint goes perfectly.” Marco (Payments PM), Wednesday: “We could lend one engineer from 6 October if the fraud work settles, but I can't promise it. Dana and our VP would need to agree.”
Tickets34 tickets: 29 done, 3 in progress, 2 blocked (both waiting on the batch-send API).
What a strong answer does

Leads with the slip: launch moves from 12 to about 26 October (23 at best), because Payments deprioritised the batch-send API for the fraud incident. Corrects last week's 'on track'. Asks Dana for the decisions only she can make: whether to move or rescope the 14 October webinar, and whether to ask the Payments VP to lend an engineer, which could pull the date in. Design progress is secondary.

Critical failures (cap the score)
  • Implies the launch is still on 12 October
  • Commits to 23 October as the new date
Case

v1.1 · synthetic · B2B SaaS, delivery risk