I'm behind and I have to decide what to drop.

What to do when you're behind and have to decide what to drop

New York, late nineteen ninety-six. Marvel Entertainment files for bankruptcy carrying roughly two hundred and fifty million dollars of debt. Its comic sales have been collapsing for years. Its stock is trading below a dollar.

The restructuring that follows in nineteen ninety-seven and nineteen ninety-eight is not a rescue of the comics business. The comics business is part of the problem.

The decision the new leadership makes — through restructuring, through litigation between Ron Perelman and Carl Icahn, through years of operational reshaping — is to drop the operational bulk of publishing and manufacturing, and pivot to licensing the characters. Spider-Man. The X-Men. The Fantastic Four. Marvel will own the intellectual property and collect licensing fees from studios and merchandisers who take on the operational risk of making things with them.

The first few years are painful. The pivot looks like capitulation at the time. Marvel has been a publishing house for decades; abandoning the publishing operation feels like abandoning the company.

It takes roughly a decade for the full consequences to become visible. Marvel Studios is formed in two thousand and five. Iron Man is released in two thousand and eight. Disney acquires Marvel in two thousand and nine for four billion dollars.

The lesson isn't license your characters. The lesson is that the thing Marvel had that was worth anything wasn't the business they were running, and the cut they had to make was the business itself. The cut everyone in the room was avoiding because cutting it meant admitting that the business they had built was not, in fact, what made the company valuable.

When you're behind and have to decide what to drop, the question isn't usually which task is least important. It's which thing you've been protecting because cutting it would admit what something else has cost.

Find what you're protecting because cutting it admits a cost

So let's go to the office and work through it.

"I'm behind and I have to decide what to drop."

The feeling is underwater.

Every option looks painful. Every option means wasting something you've already invested in. The plan you started the quarter with no longer fits the time you have left, and the discipline of cutting it down to the time available is the discipline you've been postponing.

Two choices. They look like the same problem. They need different first moves.

When sunk cost won't let you let go

Choice one: you won't let go. Every option looks painful because every option means wasting something you've already invested in. The plan is held together by sunk cost rather than by current value, and you've been ranking options by how much it would hurt to cut them.

If that's the read, cut the task that has consumed the most time with the least visible progress. Not the one you think is least important. The one you've spent most on.

Daniel Kahneman and Amos Tversky, working on what they called the sunk cost fallacy, found that people are terrible at ignoring what they've already invested in something. The investment looms larger than the future return. The only reliable way to break the grip is to cut the biggest weight first. Everything you cut afterwards will feel easier by comparison, which is the point — the first cut is the one that recalibrates your sense of what a cut costs.

When you're about to cut blind

Choice two: you haven't decided what's worth protecting. You're about to cut indiscriminately because everything feels equally compromised. The cuts will leave a release that looks like a series of compromises rather than a coherent product, because there's no centre of gravity for the cuts to organise around.

If that's the read, protect one thing disproportionately. Cut more from everything else than you need to, and use the saving to over-invest in one highly visible element. A polish detail, a launch moment, a single feature that works so well it reframes the whole release.

Will Guidara, working on what he calls unreasonable hospitality, observed that one disproportionate gesture in a constrained product can change the way the whole thing reads. You're not hiding the cuts. You're making sure there's at least one thing the user sees that proves the cuts weren't capitulation. The gesture is what keeps the release from feeling like an apology.

Sunk-cost or no-anchor. Same behind-schedule project. Two different first moves.

Cut with structure, not with instinct

Three tools. The discipline is to cut with structure, not with instinct.

Trace every item back to a top-line outcome

The first is

the Product Metrics Hierarchy.

The Product Metrics Hierarchy was popularised by Amplitude in their product-analytics writing through the mid twenty-tens, drawing on the OKR tradition codified by Andy Grove at Intel in the nineteen-seventies and the driver-tree approach to corporate finance that goes back to DuPont's analysis framework in the nineteen-twenties. The discipline is structural rather than novel.

The reason the Product Metrics Hierarchy matters when you're deciding what to drop is that the team usually can't agree on what's important until they trace each item back to the top-line business outcome it's serving. Without the trace, every feature feels equally legitimate, and every cut feels equally arbitrary.

The unique insight is the traceability requirement. Every feature on the plan has to be defensible as serving a specific top-line metric — and the top-line metric has to be defensible as serving a specific business outcome. Features that can't be traced are easy to drop, because they weren't doing anything anyone could defend in those terms anyway.

What you get is a structural test for what to cut. Not I think this matters less, which is opinion. This feature can't be traced to any of our top-line metrics, which is structural. The hierarchy does the cutting.

So. How to use it.

Define. One sentence. Activated paying customers per quarter, gross merchandise volume, daily active subscribers. Whichever your business actually runs on.

Map. Two or three input metrics that drive the top-line. Activation rate times monthly traffic. Listings per seller times buyers per listing times conversion rate. The arithmetic has to compose; if it doesn't, the lower-level metrics aren't actually drivers.

Trace. Each remaining item on the plan has to be defensible as moving one of the input metrics. If it can't be, the feature is decorative.

Cut. They were never serving anything in the hierarchy anyway. The decision is structural, not personal.

The hierarchy sometimes also reveals that the team has been investing heavily in metrics that don't actually compose into the top-line outcome — and that the top-line is being pulled by something the team isn't formally tracking at all. That diagnostic is worth as much as the cuts themselves.

Defend the funnel stage you're leaking at

The second is

Pirate Metrics.

Pirate Metrics — AARRR — was coined by Dave McClure in two thousand and seven in a startup-metrics presentation that travelled widely across the early Y Combinator and SaaS communities. The acronym stood for Acquisition, Activation, Retention, Referral, Revenue, with the deliberate joke that read out loud it was the noise a pirate makes. The framework has since become the canonical funnel diagnostic for early-stage product teams.

The reason Pirate Metrics matters when you're cutting is that funnel-stage matters. A feature improving acquisition is not interchangeable with a feature improving activation, even if the spreadsheet says they have the same expected value. The funnel is sequential — losing activation matters more if you're already doing well on acquisition, because the activation drop wastes the acquisition you've already paid for.

The unique insight is the funnel-stage diagnostic. The five letters are not a list of metrics; they are stages a single user passes through, in order. The right thing to cut depends on which stage your funnel is currently leaking at — and the wrong thing to cut is whichever stage is closest to the stage you have a problem with.

What you get is a structural reason to defend specific metrics against the across-the-board cut. Not all metrics matter, which produces no cuts. Not only revenue matters, which produces the wrong cuts. We're leaking at activation; the activation features stay; the others can be cut.

So. How to use it.

Map. Per-stage numbers. Ten thousand acquired, eight hundred activated, four hundred retained, fifty referring, two hundred revenue. The numbers don't have to be exact; the order of magnitude per stage is what matters.

Find. Which stage has the worst conversion to the next? Most teams discover their leak isn't where they assumed it was. The leak is the diagnostic.

Defend. Features serving the stage you're leaking at — and the stage immediately upstream — get protected. Features serving stages elsewhere can be cut.

Cut. With the funnel diagnosis explicit, the cuts read as structural rather than as preference. The team is cutting features that serve stages where the funnel is healthy.

The framework is what stops the team from cutting an activation feature to save an acquisition metric that looks better in isolation but matters less.

Check fast whether the remaining work fits the time

The third is

T-shirt Sizing.

T-shirt Sizing as a discipline traces through the agile estimation literature of the early two-thousands — Mike Cohn's Agile Estimating and Planning, two thousand and five, is the canonical text — and earlier through the COCOMO and Wideband Delphi traditions of software engineering estimation that go back to the nineteen-seventies. The contemporary form — small, medium, large, extra-large — is deliberately rough.

The reason T-shirt Sizing matters when you've cut down to a defensible scope is that you now need a fast estimate of whether the remaining work fits the time you have. Detailed estimation is too expensive at this stage; the team has been re-planning for a week and another week of detailed estimation is the wrong investment. T-shirt Sizing is the rapid alternative.

The unique insight is that roughness is the feature. The small, medium, large, and extra-large bands are crude on purpose. Crude estimates are fast, and they expose the gross structure of the remaining work without the team getting lost in story-point arguments. The right move at this point is fast and approximately correct, not slow and precisely wrong.

What you get is a slim, defensible version of the plan you can take to stakeholders within hours rather than weeks. The estimates aren't promises; they're a structured first cut at whether the cut-down scope still fits the available time.

So. How to run it.

Set. Pick four or five sizes. Small, medium, large, extra-large. Define each one in capacity terms — small is one engineer one week, medium is two engineers two weeks, and so on. The team has to share the definition for the estimates to be commensurable.

Size. Whole team in a room, or Slack. Each item gets a quick discussion and a size. Disagreements surface assumptions, which is useful; they don't need to be resolved with precision, which would be expensive.

Sum. Total the sizes against your available capacity. If the cut-down scope still doesn't fit, you cut more.

Re-cut. The arithmetic is brutal but clear. Either the work fits, or another round of cuts is needed. The hierarchy and the funnel from the previous tools tell you which to drop next.

The roughness is what makes this tool work in a behind-schedule context. Detailed estimation in a behind-schedule context is itself the slip, because it consumes capacity the team needs for the work.

A precedent: refusing to cut the one category that holds the future

That's the toolkit. One more story before we close.

Marvel at the cold open showed the discipline of cutting the operational core when the operational core wasn't where the value lived. The story we close with shows the inverse half — the discipline of refusing to cut a category, against pressure, because the future of the company sat in a pipeline that had not yet shipped.

Stamford, August two thousand and one. Anne Mulcahy becomes Chief Executive Officer of Xerox. The company is over seventeen billion dollars in debt, in its sixth consecutive year of losses, under SEC investigation for accounting irregularities, and being advised by external bankers to file Chapter Eleven. The stock drops fifteen per cent on the day her appointment is announced.

The cuts she makes over the next five years are severe by any standard. Over thirty thousand jobs gone. The soho consumer business killed. Capital expenditure halved. Selling, general, and administrative costs reduced by a third. Total debt cut in half.

The category she refuses to cut, against substantial pressure from bankers and investors, is research and development. As she tells the Stanford GSB View From The Top speaker series in two thousand and four — we didn't take a dollar out of research and development.

Her framing of the trade-off is structural. Avoiding short-term bankruptcy by gutting R and D could produce a long-term research drought, and Xerox's future is structurally in the pipeline she has not yet built. To anchor the team to that future, she and one teammate write a fictitious Wall Street Journal article dated two thousand and five, describing Xerox's successful turnaround as if it has already happened. Performance metrics. Made-up analyst quotes. The whole thing.

By her own later count, about eighty per cent of what is in the article materialises.

The deeper point: the harder question is what to protect

When you're behind and have to decide what to drop, the harder question is usually what to protect. Mulcahy cut everywhere her bankers told her to cut, and held the line on the one place they wanted her to cut hardest — because that was the place the company's future was structurally located, and cutting it would have been cutting the company's reason to recover.

So. Your Next Move from this playbook.

What's still on the plan because cutting it would admit what last quarter cost — and whose face are you saving by keeping it?