Chapter 03 of 06
NYT Games killed 97% of their ideas to find Wordle. Most orgs do the opposite — they keep funding things they know aren't working. Stopping is the rarest capability in most orgs — because nobody teaches it.
New here? Start with the overview for context on why failure matters.
Based on: Jordana Stein (LinkedIn, 2024) · Scott Kirsner (HBR, 2017)
of game concepts NYT Games tested were killed before Wordle, Connections, and Spelling Bee could exist
"Every game you put out becomes something you have to support forever. It's resource-intensive. It's a drag on the system."
— Jonathan Knight, SVP & Head of NYT Games
NYT Games didn't succeed despite this philosophy. They succeeded because of it. The 97% that died are what made the 3% possible.
The NYT Games model
30-day retention. One number. Games that fail the filter die — no committees, no second chances, no "but we already invested so much." The metric is pre-committed before the test begins.
Sunk cost is not a reason to continue. The fact that a team spent six months on a concept is irrelevant to whether it's worth shipping. The question is always forward-looking: will people come back?
Every game you don't ship is resources freed for the next test. NYT Games treats killing as an investment in future bets, not a failure. The org is a testing machine, not a portfolio manager.
What this means for your org: Organizations that can't kill things accumulate drag. Every product, program, or initiative you keep running requires support, attention, and people. Most orgs fail not because they can't generate ideas — but because they can't say no to the ones that aren't working. NYT Games has clarity about what success looks like. Most organizations don't.
The other place things die
Scott Kirsner's HBR research on 164 executives at billion-dollar companies found something counterintuitive: the problem isn't the ideas. Organizations generate plenty of viable concepts with early customer validation. The failure point is what happens after — the handoff from R&D to the business unit responsible for scaling.
say the handoff "needs serious work"
call it "terrible" — watched projects die post-transfer
Recent casualties include innovation programs at Target, Alaska Airlines, Coca-Cola, the New York Times, and Chubb — all quietly expired within three years. Not because the ideas were bad. Because nobody owned the transition.
Why handoffs fail
The R&D team knows why they made every decision. The business unit doesn't. By the time a project moves, the institutional knowledge is gone.
Business units inherit projects without the budget, headcount, or mandate to scale them. They're being handed a baby they didn't ask for.
Sales teams have quotas. Operations has SLAs. The innovation project is interesting until it competes with their real job — and then it drops.
Who is responsible if this fails? Usually nobody. When failure isn't owned, killing isn't either.
Business units fund and shape innovation from the start. Best performers involve BU leaders in agenda-setting (85%) and co-fund the work (46-70%). Don't hand off. Transition together.
A framework
Before you launch, define exactly what would make you stop. One metric, a specific threshold, a specific date. If you can't name it in advance, you're not running an experiment — you're running a program you're already emotionally invested in. Pre-commitment is the only protection against sunk cost reasoning.
The longer you let something linger, the more energy it consumes from people who already know it's not working. A fast, public kill — with honest explanation — builds organizational trust. "We tried this, it didn't work, here's what we learned" is more credible than a program that quietly fades away with no conclusion.
The project failed. The team didn't. NYT Games doesn't fire designers when concepts die — they move to the next test. If killing a project also kills people's confidence or careers, you will never build a culture that can kill fast. Make it structurally safe to be associated with a dead project.
Within 48 hours of killing a project, run a short post-mortem: what assumption was wrong, what data surprised us, what would we do differently. This is the only thing that converts failure into asset. Without it, you just paid for nothing. With it, you've bought insight that informs the next bet.
In missions culture, we often conflate perseverance with persistence. But persevering in the wrong direction is not faithfulness — it's stubbornness. The most faithful thing you can do with a failed program is name it clearly, learn from it honestly, and free the resources for the next thing.
The programs that do some good are the hardest to stop. They have real beneficiaries, real champions, real inertia. But "some good" is not a reason to keep going if the core model isn't working. Pre-commit to your criteria. Then trust them.
Key Takeaways
Sources