Every half year business review I've sat through starts the same way: someone opens a slide deck from January, reads the goals out loud, and the room nods. Nobody asks the only question that matters. Of the ten things you said you'd do, how many actually exist in the world right now, being used by a customer or an employee?

That gap between "planned" and "shipped" is where most businesses quietly bleed. Not from bad ideas. From good ideas that never left the building. If your mid-year review is a rehash of the plan instead of an audit of output, you're grading yourself on effort, not results.

I run this exercise with clients every June and December. It takes twenty minutes and it's uncomfortable on purpose.

The three-bucket audit

Pull your January list, whatever it was: a strategy doc, a set of OKRs, a whiteboard photo. For each item, put it in exactly one bucket.

  • Shipped. It's live. Someone outside your team touches it or feels its effect.
  • In progress. Work has happened, budget has been spent, but nothing has gone out the door.
  • Quietly dead. Nobody's touched it since February and nobody's said so out loud.

Most owners are shocked by how small the "shipped" bucket is compared to how much energy went into "in progress." That's the diagnostic. The review isn't really about what you did, it's about where the energy went versus where the results came out.

In progress is the dangerous one, not dead

Dead initiatives are honest failures. Everyone secretly knows they're not happening, and that's fine, priorities shift. The real damage comes from the in-progress bucket, because it lets you feel productive without producing anything.

An initiative that's been "80% done" since March is not 80% done. It's a commitment you've made to yourself that costs money and attention every month while returning nothing. I've seen this with a multifinance company that spent five months "finalizing" a new collections dashboard. Every review, the answer was "almost there." When we finally forced a ship date, the team delivered a smaller, uglier version in three weeks that did 70% of what was originally scoped, and it was enough. The other 30% never got missed.

The lesson isn't that planning is bad. It's that scope creep disguised as thoroughness is what keeps things permanently in progress. A related failure mode: subscription creep works the same way, tools pile up because nobody does the equivalent audit on spend.

Why finished and imperfect beats polished and stuck

A shipped feature that's 70% right generates real feedback. Customers use it, complain about it, ignore it, something happens, and that something tells you what to build next. A feature sitting in progress generates zero feedback no matter how well-designed it is on paper.

This is the core trade owners get backward. They protect unfinished work because it still holds the promise of being perfect. But promise doesn't pay invoices or fix churn. Only shipped things do. If you're choosing between build vs buy for your next initiative, the same principle applies: buy the boring thing that ships this quarter over building the perfect thing that ships next year.

Running the review without the excuses

When you do the three-bucket exercise, expect pushback. People will want to explain why something is still in progress. Let them explain once, then move to the fix, not the justification.

  1. List every H1 initiative, no matter how small.
  2. Bucket honestly, without asterisks or "it's basically shipped."
  3. For anything in progress over 60 days, force a decision this week: ship a smaller version in two weeks, or kill it.
  4. For anything dead, say so out loud in the review. Free up the budget line.
  5. Write down, next to each H2 initiative, one sentence answering "what's the smallest version that ships in 30 days."

That last step is the actual output of the review. Not a new plan. A smaller plan with a hard finish line.

Setting up H2 so this doesn't repeat

The fix for chronic in-progress work is scope discipline before the work starts, not accountability after. When you set an H2 initiative, write the finish line before you write the task list. "Ship the customer portal" is not a finish line. "Customers can log in and see their invoice by August 15" is.

Cut every initiative in half before you start it. If the honest estimate is three months, scope it to six weeks and cut features until it fits. You will be wrong about scope either way, but erring toward smaller means you're wrong in the direction of shipping early, not stalling late.

Assign one owner per initiative who reports a binary status, shipped or not shipped, every two weeks. Not "70% done." That number is almost always fiction anyway, since the last 20% of most projects takes as long as the first 80%.

The takeaway

Your half year business review should produce one output: a shorter list of things, each with a date attached, and an honest count of how many things from January are actually running today. If that number embarrasses you, good, that's the review doing its job. Cut scope, pick finish lines, and report binary status. Do that consistently and your year-end review looks nothing like the one you just sat through.