The job-to-be-done here is specific, and it is not "aggregate trending topics." Google Trends already does that well, for free, and products like Exploding Topics already package rising search interest for marketers who need to spot a category before it peaks. A reader hiring a Duck Times product to do the same thing has no reason to pick us over either of those.
The actual job is different: show a reader what a newsroom did with a signal they could look up themselves. Every newsroom keeps some internal version of a trend radar — a dashboard editors glance at before assigning a story — but it has always been invisible, a black box that either produces good editorial decisions or doesn't, with no way for anyone outside the building to check which.
The Labs prototype takes the same category of signal Google Trends already surfaces and pairs it with the editorial decision made on top of it: which spikes got picked up, why, and which were deliberately passed over. The radar itself is not the product. The gap between raw signal and editorial judgment, made visible, is the product.
That visibility creates accountability that pure internal judgment never had. If the public radar shows a spike Duck Times chose not to cover, that choice becomes inspectable rather than invisible by default, which raises the bar for the reasoning behind every pass, not just every story that ran.
Done well, this could become useful beyond Duck Times itself — a way for smaller newsrooms or independent writers to see what's rising in a category without building their own trend-monitoring infrastructure, paired with a visible example of editorial filtering being applied to it in real time.
The harder design problem, still unsolved, is presentation: how to show that a spike was seen and deliberately not covered without it reading as arrogance or after-the-fact excuse-making. This is an early-stage Labs project, not a finished product, and that presentation question is the one thing that has to get solved before it ships anywhere near readers.