Kill the OKR. The Quarterly Cycle Is Now a Liability.

I know. I'm going after OKRs.

This is the fight I'm least looking forward to in this Kill the X series, because OKRs have been canonized. Andy Grove wrote about them. John Doerr evangelized them. Christina Wodtke literally wrote the book. Every operator I respect has some version of OKRs in their toolkit. The framework is genuinely good for the problem it was designed to solve.

My argument isn't that OKRs never worked. My argument is that the problem they solved is a 2010s problem, and we now live in a different operating environment where the quarterly cycle is actively harmful. OKRs have to go, or at least get reduced to a small-scope diagnostic tool, and what replaces them is a faster, more honest system.

This is the most controversial post in the Kill the X series. I expect the pushback. Here goes.

The short version

The 12-week OKR cycle was built when build cycles were weeks and learning cycles were months. In 2026 a Product Builder ships a working prototype in four hours, customer signal arrives daily, and high-performing teams are 4-6 people. A quarterly commit is now a lagging response. Replace OKRs with a Rolling Outcome Ledger: three to seven active outcome bets at any time, each with a hypothesis, a test, a 2-4 week decision deadline, and one owner. Keep quarterly cadence only for board narrative and capital allocation that has long lead times. Strip everything else.

For more on the broader rebuild, see Kill the PRD and Kill the Feature Request Queue. For the planning artifact that replaces the quarterly OKR doc on the board agenda, see The CPO Mandate 2026.

What OKRs were actually for

The OKR system (Objectives and Key Results) solved a specific problem for growing tech companies between roughly 2000 and 2020. The problem was:

• Organizations were getting bigger and harder to coordinate
• Annual planning was too slow to respond to markets
• Teams needed shared language for ambition and progress
• Leadership wanted to cascade strategy without micromanaging

The quarterly rhythm was a trade-off. It was fast enough to reflect real-world change, slow enough to produce genuine ambition, and big enough that people took it seriously. Objectives were the direction. Key Results were the measurable proof that you were moving.

Done well, the system was a hell of a coordination tool. A Google-scale organization could have thousands of teams working roughly in the same direction because OKRs were the language of alignment.

The problem isn't that OKRs stopped being true. It's that the cycle time they were built around (12 weeks of commit-then-deliver) is now slower than the cycle time of the work they're meant to measure.

Why the 12-week cycle is now a liability

Three things have changed the operating cycle of a product team.

1. Idea-to-prototype is now hours, not weeks

If a Product Builder can go from "we should try this" to a working, deployed prototype in four hours (and they can, with Claude Code), then a three-month plan written in week one of the quarter is going to be irrelevant by week four. You will have learned so much from week-one, week-two, and week-three prototypes that the plan's premises are outdated.

This was not true in 2015. In 2015, a quarterly plan was about right, because the build cycle was weeks and the learning cycle was months. Now they've collapsed.

2. Customer signal arrives continuously

In 2026, you have agent telemetry, eval scorecards, and signal synthesis pipelines that surface customer patterns daily or weekly. The OKR system was built for a world where customer signal arrived quarterly (from surveys and sales reviews) or monthly (from usage reports). When the signal is daily, a quarterly commit is a lagging response.

3. Team composition has gotten smaller and faster

The teams that outperform now are small. Four to six people. Shipping on tight loops. An OKR cycle that assumes a large team with multiple workstreams is overfit for that scale. Small fast teams are held back by the ritual, not accelerated.

Taken together, the quarterly OKR cycle now creates five specific problems:

• The mid-quarter replan. Every team I know that runs OKRs has to replan mid-quarter because reality has moved. This is normal. The problem is that the replanning isn't built into the cycle, so it happens as an apology or a working-around.
• The sandbagged KRs. Key Results that the team is 90% sure they can hit. The cycle length rewards sandbagging because missing a KR feels like a quarterly failure, even if you were right to try.
• The vanity objectives. Objectives that sound good in the quarterly planning doc but that no one would bet their performance on if the cycle were shorter.
• The end-of-quarter scramble. The last two weeks of every quarter get distorted by OKR attainment, not customer value. This is not what Andy Grove designed for.
• The overhead tax. Writing, reviewing, cascading, and scoring OKRs takes meaningful time. At quarterly cadence, the overhead is significant. At the cadence required in 2026, the overhead would be crushing.

The diagnosis is that the cycle is wrong. The treatment is not "do OKRs better." The treatment is a different system.

What replaces the OKR

Here's the replacement I use, and have used with several teams over the last 18 months. I call it the Rolling Outcome Ledger. It's less catchy than OKRs. I'm open to better names.

The ledger

A single list, visible to the whole team, with three to seven active outcome bets at any time.

Each bet has:

• A specific outcome. Not "improve activation." "Move 14-day activation rate from 38% to 43% for new enterprise signups." Specific, measurable, and with a baseline.
• A hypothesis. Why you think this bet will move the outcome. One sentence.
• A test. The prototype or experiment that will determine whether the hypothesis holds.
• A decision deadline. Usually two to four weeks from entry. Not a quarter.
• An owner. One name.

Bets enter the ledger when the team commits to testing them. Bets leave the ledger when the decision deadline hits: either they paid off (and go to production), they didn't pay off (and are retired), or they produced a partial signal (and get rewritten into a new, narrower bet).

The cadence

Weekly.

Every Monday, a 30-minute review. Three questions per bet:

1. What did we learn this week?
2. Is the deadline still reasonable?
3. Do we have what we need?

Every Friday, a five-minute update: what moved. Bets that paid off, bets retired, new bets entering.

That's it. Thirty-five minutes of formal review per week. No cascading. No scoring. No end-of-quarter scramble.

The quarterly check

Once a quarter, a three-hour session. Two questions:

1. Looking at the last 12 weeks of bets, what patterns should change?
2. What new bets should we set up for the next 12 weeks?

This is the only place the quarterly cycle still lives. It's a retrospective and a reset, not a plan-and-commit. The output is not a scored OKR deck. It's an updated ledger and a short written synthesis.

Why this is better

Five things improve when you switch.

1. Honesty goes up. Because bets have short horizons, the team doesn't sandbag. A bet that's going to take two months is fine. A bet that's going to take a quarter is suspicious, because you've committed to something you can't learn about for too long.
2. Learning velocity goes up. When a bet is retired after three weeks, the team writes a real retrospective. The learning enters the team's model of the product. In OKR world, a failed KR gets scored 0.3 and forgotten.
3. The end-of-quarter distortion disappears. There is no end of quarter. There are rolling deadlines for specific bets, distributed throughout time. No scramble, no attainment theater.
4. Communication with leadership improves. The ledger is always current. A CPO or a board member can look at it on any given Wednesday and see what the team is working on, what's paying off, and what's retired. No quarterly reveal.
5. Small teams can run it themselves. A four-person pod can run the rolling outcome ledger with zero overhead. An OKR process for a four-person pod is ridiculous but common. The lighter system fits the smaller team.

The objections

I expect five big ones.

"OKRs work. I've seen them work."

You have. I have too. The argument isn't that OKRs never worked. It's that the conditions that made them work (slower build cycles, monthly signal, larger teams) have changed enough that the framework is now fighting the operating environment, not supporting it. Don't argue against OKRs-in-general. Argue against the cycle length, which is the actual claim.

"We need cross-team alignment. OKRs are how we get it."

You need alignment on direction, not on quarterly commitments. The Rolling Outcome Ledger is compatible with quarterly strategy sessions where cross-team direction gets set. What changes is that teams don't cascade KRs down from those sessions. They set their own bets, informed by the direction. Alignment on "what direction" happens quarterly. Alignment on "what bet" happens weekly.

"Our CEO and board are OKR-aligned. We can't just stop."

You don't have to stop everywhere at once. Most of the pushback against dropping OKRs comes from the layer where they were actually working reasonably well (executive-level annual direction-setting). Keep that layer. Drop the cascade. The CEO's top three OKRs for the year can still exist. What goes away is the quarterly cascade to every team below them, because that's where the cycle-mismatch problem lives.

"If we don't score OKRs, how do we measure performance?"

This is the question I hear most. The honest answer is that quarterly OKR scoring was never a great measure of performance. It measured whether the team had set achievable goals and executed them. It conflated setting good goals with being a good team.

In the Rolling Outcome Ledger, performance is measured directly by the outcomes moved. Did the product's metrics improve? Did bets pay off at a reasonable rate? Are retros producing learning that shows up in later bets? Those are harder to grade on a curve, but they're truer signals of team effectiveness.

Some orgs will want a more structured review. A simple quarterly review of: outcomes moved, bets paid off versus retired, learning per bet, and quality of the retros. No scoring. No curves. A conversation.

"This is just a fancier version of shape-up / continuous planning / [other framework]."

Somewhat. I'm not claiming this is new. The ideas are borrowed from Shape Up, from continuous discovery, from agile-at-its-best, and from how the fastest teams I've worked with already operate. The contribution of this post is naming the argument specifically against OKRs for small, fast, AI-augmented product teams, and offering a concrete minimum-viable alternative.

If you already run something that achieves the same thing, you don't need to rename it. Keep what works.

The transition

If your org runs OKRs and wants to move to a Rolling Outcome Ledger:

Month 1: Keep OKRs at the top level. Stop cascading them to pod level. Each pod starts running an outcome ledger with three to five bets.

Month 2: Compare. Look at what the pods accomplished on the ledger versus what they would have been doing on their OKRs. In almost every case, the ledger will have produced clearer learning, and the OKR-shaped work would have been the same work but with more overhead.

Month 3: Based on the comparison, decide. Most orgs I've done this with drop cascade-OKRs entirely after month three and keep top-level OKRs as a strategic communication tool. Some go further and drop even the top-level ones. Both are defensible. The cascade, though, has to go.

The fight I'm picking

I'm naming the people and ideas I'm arguing against because I respect them. Christina Wodtke's book on OKRs is genuinely useful, and I think her descriptions of the framework's failure modes are mostly correct. I'm not saying she's wrong about how to run OKRs. I'm saying the framework itself is overfit for a slower era, and I think she'd be the first to grant that the right cadence depends on the operating conditions.

John Doerr's Measure What Matters made OKRs famous. The framework's actual value (focus, alignment, tracking) is real. My argument is about the cycle length, not the underlying ideas.

Andy Grove invented the structure for Intel in a completely different operating environment. He was a better operator than almost anyone writing about his framework today. If he were running a four-person AI-native pod in 2026, I'd bet he'd be running something closer to the Rolling Outcome Ledger than to modern cascaded OKRs.

Where to start

If your team runs OKRs right now, this week you can do one thing.

Pull the three most important Key Results your team committed to for this quarter. Write a two-line answer to each of these questions:

1. What would you do differently if the deadline on this KR were three weeks from now, not end of quarter?
2. If this KR turns out to be wrong halfway through the quarter, is there a formal process for retiring it?
3. How much time has your team spent on OKR ritual (writing, reviewing, updating, grading) in the last month?

The honest answers to those three questions are usually enough to make the case internally. The faster deadline would sharpen the work. There isn't a real retirement process. The ritual cost is meaningful.

If you want to go further, set up a Rolling Outcome Ledger for just one pod next week. Three bets. Weekly review. Retire or productionize based on the data. Give it a quarter. Compare.

Kill the OKR. Build the ledger. Ship faster. Learn more.

---

The Rolling Outcome Ledger template, weekly review agenda, and one-page retrospective format are all on the toolkit at falkster.com/toolkit.

Further reading

• Christina Wodtke on using and breaking OKRs (Radical Focus)
• John Doerr and the What Matters foundation on measuring what matters
• SVPG on the chronic dysfunction of feature-output OKRs
• Lenny Rachitsky on how AI-native teams are rethinking quarterly planning