Two-Mode Product Teams
One team, two clocks: ship at the speed of the moment, and build the system between moments
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 90%
In domains where events move faster than roadmaps, Hardiman's storytelling product team operates in two distinct modes. Mode one: work alongside domain experts in the moment, without complete data, and make a call on the best experience right now. Mode two: when not shipping at the speed of news, build the end-to-end systems — the creation tooling and the consumer experience together. The same team must be able to switch between the two, because the in-the-moment work is what reveals which systems are worth building.
Origin
Alex Hardiman's description of the New York Times storytelling product team and its relationship with the newsroom's graphics, visual journalism and interactive news teams.
Core principles
- 01When the domain moves faster than a roadmap, exempt the frontline team from roadmap process
- 02In-the-moment mode accepts judgment calls without complete data
- 03System mode builds creation tooling and consumer experience at the same time, not sequentially
- 04The one-off experiments are the R&D pipeline for the platform
- 05The scoreboard is what fraction of work runs on the platform rather than as a one-off
How to run it
- 1
Free the frontline team from roadmap process
Give the autonomous, domain-embedded team (editors, journalists, engineers, data scientists, designers hunkered down together) explicit exemption from normal roadmap and prioritisation processes so they can focus purely on making one thing come to life.
Pro tip The idea should originate with the domain expert — the reporter who has covered the beat for decades has the nugget — and they pull in the interactive/visual/data specialists.
Watch out This only works if the exemption is real. A 'fast team' that still has to queue for roadmap slots is just a slow team with a nickname.
- 2
Run one-offs as genuine experiments
Let the most inventive formats start life as one-off experiments spun up by the embedded team, with no obligation to be reusable. The goal is maximum impact for this one story.
- 3
Have a separate product team watch for what's working
Stand up a storytelling (format/platform) product team whose job is to notice which experimental one-offs are starting to work, and to work with domain experts to test and find product-market fit for those formats.
Pro tip Treat a format like a product: it needs its own PMF test before it earns platform investment.
- 4
Promote proven formats to the platform
Scale the formats that found fit across the whole output — so that over time the composition of the product shifts (more video, visuals, live) and each new instance is cheaper, more accessible and more engaging than the last.
- 5
Build the tooling and the consumer experience together
In system mode, build the creation tools that produce the content at the same time as the consumer experience that renders it. This is the mode-two system-level thinking that turns a magical one-off into a repeatable capability.
Pro tip Track the ratio: at the Times, 'the majority' of these stories run on the platform, hands down. If the ratio isn't moving, mode two isn't working.
Watch out Shipping the consumer experience without the creation tooling means every future instance is a one-off again.
In the wild
Investigative reporter Jodi Kantor reported a piece on how employers track and monitor remote workers with tools like productivity scores. The embedded team designed the story to show the reader's own productivity score in the moment as they read the article.
→ Hardiman: 'super visceral, really creepy in the most effective way' — the kind of magical experience that only happens when dedicated designers and engineers sit down with a reporter, and exactly the kind of one-off the storytelling product team then mines for scalable format patterns.
Live reporting was developed as a format where reporters file tweet-length updates from the ground — for example from Ukraine — giving immediacy that the traditional article structure could not. The storytelling product team scaled this into the platform.
→ The distribution of stories shifted away from the traditional article into video, visuals and live, making the app more accessible and more engaging without a bespoke build per story.
Common mistakes
Forcing the fast work through the roadmap
'The speed of news is so fast that you don't have time to mess with road maps.' If in-the-moment work has to be planned like normal work, it either arrives late or never gets attempted, and the experimental pipeline that feeds the platform dries up.
Letting one-offs stay one-offs
Without a team explicitly watching for which experiments are working and finding PMF for them as reusable formats, every impressive piece stays an expensive bespoke build. The two modes only compound when mode two harvests mode one.
Is it for you?
Best for
Product leaders in event-driven domains (news, live sports, incident response, trading, elections) where high-impact work outruns any planning cycle
Not ideal for
Steady-state product areas with predictable demand, where a normal roadmap is a better allocation mechanism than dual-mode autonomy
From the transcript
“And the speed of news is so fast that you don't have time to mess with road maps.”
“But on top of that, what we do have is a storytelling product team. And what they do is they really kind of take notice…”
“First, they have to be able to think in the moment with editors where you might not always have all the right data at your…”
“And then the other mode is when they're not shipping at the speed of news, they're trying to build end-to-end systems so that we're building…”
“The majority are on our platforms, um hands down.”
From the episode
An inside look at how the New York Times builds product
Alex Hardiman (CPO at The New York Times)