Prioritisation Under Real Constraints

Two things are on the table and you can fund one.

The first is a rebuild of the onboarding flow. Three of your last five enterprise losses mentioned it. Your head of sales wants it and has wanted it for a year.

The second is a set of integrations two large existing customers have asked for by name. Both are up for renewal in the spring. Together they are 19% of revenue.

Both are good. Neither is a mistake. Every argument you can make for one, someone competent can make against — and they will, in the meeting, and they will be right about the parts they are right about.

The chapters before this one gave you tools for telling a good proposal from a bad one. This is different. Here both proposals are good, and the previous tools return yes on both.

Notice what people actually do in this room. They argue about which option is better, for an hour, and the argument does not converge, because it cannot: the options are not comparable on a single scale. Eventually someone senior decides on feel and the meeting ends with everyone slightly unsatisfied.

The question this chapter answers: when both options are defensible, what decides — and what does a good decision look like on paper afterwards?

Compute the constraint before you argue about the choice

Before the onboarding-versus-integrations argument is worth having, there is a number nobody in that room has said out loud.

Given current revenue, current growth rate, and current expenses — and assuming no new funding — does the company reach profitability before the money runs out? A company where the answer is yes is default alive. Where the answer is no, it is default dead.

This is not a mood. It is arithmetic on numbers you already have: monthly revenue, its growth rate, monthly costs, cash in the bank.

Why it goes first. It determines which arguments are admissible. A default-dead company does not get to make bets whose payoff lands after the money runs out, however strategically attractive they are. Once you know the answer, an argument about vision becomes an argument about constraints, and constraint arguments converge.

How to use it. Compute it before the debate, not during. Then state it at the top of the plan, and scope the plan to it. The characteristic error is discovering the answer late, when every remaining option is bad — and the reason it is discovered late is that the calculation forecloses things the team is emotionally committed to.

How to spot the gap. A resourcing plan with new headcount, multi-quarter payback, and no runway figure anywhere. There is always a plausible story about the next raise or the next big customer, and the story is doing the work the arithmetic should be doing.

One thing that has changed. Lower build costs shift the number and rarely reverse the conclusion. Headcount, distribution, and sales remain the dominant costs for most companies, and cheaper building tends to be spent on more surface area rather than banked. "AI makes us more efficient" is a hypothesis with a measurable answer, not runway.

Comparison is what makes a tradeoff visible

Here is a document you have read many times. It recommends one course of action. It is well argued. Its risks section lists three things that could go wrong in execution: the timeline might slip, a vendor might be late, a hire might take longer than expected.

Read it again and ask what else was considered. Usually: nothing that made it to the page.

A single-option proposal is a decision that already happened. The document is not making a choice, it is transmitting one — and that is fine, as long as everyone knows which of the two is going on. The trouble is that it looks identical to a decision document, so readers evaluate it as though there were something to decide.

How to use it. Require the real alternatives with their costs, including the option of doing nothing. Three is a reasonable floor. And watch for the fake set: two obviously worse options flanking the intended answer, which is advocacy wearing a comparison's clothes.

If the author is genuinely confident, the comparison costs them nothing. It gives readers something specific to disagree with, which is how disagreement gets surfaced early instead of six weeks in.

How to spot it. The risks section lists execution risks only. No belief risks — nothing of the form "this only works if X is true, and we do not know that X is true."

One thing that has changed. Generating the alternative branches is now nearly free, which removes the last excuse for a single-option proposal. It also floods the comparison with plausible options nobody has evidence for. Three generated alternatives are not three considered alternatives; the work moved from producing options to pruning them.

Say what the chosen option costs

Every real choice sacrifices something. This is not a moral point, it is a structural one: if an option cost nothing, it would not be a choice.

So a proposal in which every consequence is a benefit — faster and cheaper and better for users and strategically superior — has either not found the cost or is declining to name it. From the reader's side those are the same problem, because either way the reader cannot evaluate it.

How to use it. Ask what the option sacrifices and who bears it. Look specifically for: work deferred and by how long, the segment not served, the complexity added, the reversibility lost, the person or team who now has a worse quarter.

Then write it down, in the document, in the author's own voice. A named cost is what turns advocacy into a decision — and it is the single highest-signal line in most product documents, in both directions. Its presence is the strongest evidence of real thinking; its absence is the most reliable tell of shallow product thinking.

How to spot it. Search for the sentence beginning "what we give up." If it is not there in some form, it has not been thought about, because thinking about it is not the kind of thing you do and then forget to mention.

One thing that has changed. Fluent drafts are especially prone to costless tradeoffs, because the register of confident business writing has no natural place for "and this will hurt." The cost line is one of the small number of things you have to add on purpose.

Find the load-bearing assumption before writing the plan

Plans allocate resources against assumptions. Most plans do not say which ones.

Before writing the plan, list what must be true for it to succeed, and mark each item evidenced or assumed. Then find the item that is both load-bearing and unevidenced. That is not a footnote to the plan — it is the first thing the plan should do.

How to use it. Test the riskiest assumption first, with the smallest test that could change your mind. The plan then either gets evidence or gets cancelled early, and early cancellation is the cheapest possible outcome. This also gives the team something concrete to go and find, instead of a quarter of building.

How to spot it. Same tell as before, and it recurs because it is the tell: a risks section made of execution risks only.

Back to the two options

With the concepts in hand, the room is a different room.

Compute first: if the runway is nine months and the onboarding rebuild pays back in twelve, the argument is over before it starts, and it was never really an argument about product.

Compare properly: onboarding rebuild, integrations, and at least one option neither side proposed — the smallest version of the integrations that satisfies the renewal, which frees most of the quarter.

Name the cost: choosing integrations means enterprise win rates stay where they are for another year and the head of sales is right about that, in public, for four quarters. That sentence belongs in the document, not in the meeting.

The plan that got smaller and shipped

Tomas runs a 24-person company selling compliance software. Revenue is £310k a month, growing 4% monthly, costs are £395k a month, and there is £2.1m in the bank. A raise is "expected in Q1."

The Q3 plan proposes four hires and two major initiatives.

Tomas computes before the meeting rather than during it. At 4% monthly growth and flat costs, revenue crosses £395k in roughly twenty-two months. Cash covers about twenty-five months at the current gap, narrowing as revenue grows. So: default alive, but not comfortably, and only if costs stay flat — which four hires directly contradict. With the hires, costs go to roughly £465k and the crossing point moves out past the cash.

That single calculation converts the meeting. It is no longer a debate about whether the initiatives are good — they are — but about which subset keeps the company default alive without the raise.

The plan that ships has two hires, one initiative, and a line at the top stating the runway and the assumption it rests on. It is smaller than what anyone wanted.

Two things are worth noticing. First, the arithmetic did not make the decision; it made the decision about something answerable. Second, the plan that respects the constraint is much more likely to actually happen, which is the part that gets lost when people treat this as pessimism.

The costless tradeoff, made honest

A platform team proposes migrating to a new job-processing system. The memo is strong: more reliable, cheaper to run, better observability, easier hiring, and the migration is "mostly mechanical."

Every consequence in the memo is a benefit. That is the tell, and it does not mean the memo is wrong — the migration may well be correct.

The reviewer asks one question: what does this cost, and who pays it?

The answer, once someone goes and looks, is specific. Two engineers for seven weeks, which is the quarter's second initiative not happening. A two-week window where both systems run and on-call is genuinely worse, borne by four people who were not in the meeting. And a piece of reversibility: the new system's queue semantics differ in a way that makes going back expensive after the first month.

The recommendation does not change. The migration still looks right.

What changes is that the on-call cost gets scheduled deliberately rather than discovered, the deferred initiative gets renegotiated with the person who owns it instead of being quietly dropped, and the reversibility deadline becomes a date someone is watching.

This is the ordinary case, and it is worth being clear about it: naming the cost usually does not reverse the decision. It changes what happens after the decision, which is where most of the damage from unnamed costs actually lands.

The third option nobody proposed

Back to the two bets from the start of the chapter. Onboarding rebuild versus integrations for two renewing customers.

The room has been arguing for forty minutes. Someone asks the sideways question: what is the opportunity behind each solution?

The onboarding rebuild serves "enterprise buyers can't evaluate us in a trial." The integrations serve "existing large customers can't get our data into their stack."

Stated that way, a third option appears that neither side proposed. The two renewing customers do not need the full integration suite — each needs one specific data flow, which they have said, and which is roughly a fifth of the work. Building exactly those two flows secures the renewals and leaves most of the quarter for onboarding.

This is not a compromise. Compromises split the difference and satisfy nobody. This came from tracing both solutions up to the opportunity they served and then noticing that one of them had been scoped as a category rather than as a need.

The honest cost, which goes in the document: the two customers get a narrower integration than they asked for, and a third large customer who wanted the same suite gets told no this quarter. Somebody has to make that call and own it.

A resourcing decision under a closing runway

An invented composite, built from the pattern rather than any real company.

The situation. A B2B analytics company, 31 people, four years old. Revenue £480k monthly, growing 3% monthly, costs £610k monthly, £3.4m cash. A Series B process has been "in early conversations" for two months.

Three demands on the next two quarters:

1. The platform rebuild. The original data pipeline is at its limit. Engineering says another year of feature work on top will be increasingly expensive. Nine months, most of the engineering org.
2. The enterprise tier. Sales has four prospects who need SSO, audit logs, and a security review, worth roughly £70k monthly combined. Three months.
3. The retention problem. Mid-market cohorts decay steadily from month four. Nobody knows why. Discovery would take a quarter before anything gets built.

Each has a competent advocate. The CTO on the rebuild, the CRO on enterprise, the head of product on retention. Each is right about their own domain.

Compute first. Cash covers about twenty-six months at the current £130k gap. At 3% monthly growth, revenue crosses £610k in roughly eight months, so the gap closes before the cash does — default alive, assuming costs stay flat and growth holds.

That changes the shape of the argument immediately: this is not a company that must take the fastest revenue. It has time, conditionally.

The load-bearing assumption. What must be true? That 3% growth holds. And the retention problem is precisely a reason to doubt it — a mid-market cohort decaying from month four is a leak, and the growth rate is a net number. If gross new revenue is growing 5% and churn is eating 2%, the arithmetic that produced "default alive" is measuring something unstable.

Nobody knows which it is, and it is the assumption everything else rests on. That is the top-right corner.

What actually gets decided. Not a priority order. First: two weeks, two people, to decompose the growth rate into gross new and churn, by cohort. Two weeks, not a quarter, because this is a measurement question and not yet a product question.

Then the branch, written down in advance so it cannot be reinterpreted afterwards:

• If growth is mostly gross-new and churn is stable, the company is default alive and can afford the rebuild. Enterprise tier waits a quarter; retention gets discovery in parallel.
• If churn is material and rising, "default alive" was an artifact, the enterprise tier goes first for the revenue, and the rebuild is deferred with an explicit acknowledgement that deferral makes it more expensive later.

The cost, named. In the first branch, four enterprise prospects go cold and the CRO carries a bad two quarters through no fault of theirs — and that gets said to them directly rather than discovered. In the second, the rebuild is deferred a year and the CTO's warning about compounding cost is accepted as a real debt, with a date to revisit.

What makes this good. Not the answer — reasonable people could take either branch. It is that the decision was made about a computable question, the assumption everything rested on was tested before resources moved, and the branch conditions were written before the data arrived, so the result could not be interpreted to suit whoever argued loudest.

Where it could still go wrong. Two weeks becomes six because the definition of churn turns out to be contested — which is chapter three's problem showing up inside chapter four's. And the branch conditions get quietly renegotiated when the data is ambiguous, which is what pre-committing exists to prevent and is exactly when it is hardest.

The large customer's roadmap demand

An invented composite.

The situation. A workflow product, £8m annual revenue. The single largest customer, at £900k annually and up for renewal in five months, has asked for a capability that would take a quarter: a permissions model matching their internal org structure, which is unusual and, as far as anyone can tell, unique to them.

The account team says the renewal is at risk. Product says it is bespoke work that will benefit nobody else and will complicate the permissions system permanently. Both are right.

Compute first. The company is default alive with 14 months of runway and modest profitability. So this is not existential either way, which is worth establishing because the account team's framing implies it is.

The comparison, properly done. Four options, not two:

1. Build it. Secures the renewal. Costs a quarter, and adds permanent complexity to a core system every future feature must respect.
2. Decline. Preserves the roadmap. Risks 11% of revenue, though "risk" is doing a lot of work in that sentence — nobody has established the renewal actually turns on this.
3. Build the general version. A more flexible permissions model that covers this customer as a case. Two quarters instead of one, benefits everyone, and may not land before the renewal.
4. Build the narrow version behind a flag, with an end date. Six weeks, isolated from the core model, explicitly temporary, with a written commitment to replace it with the general version within a year.

Option 4 exists only because someone asked what the customer actually needs rather than what they asked for. Their request was a solution; the underlying need is narrower.

The load-bearing assumption. That the renewal genuinely turns on this. Nobody has tested it. It came from one conversation with one champion, and champions overstate — not dishonestly, but because they are advocating internally too.

The smallest test that could change the answer: a direct conversation with the economic buyer about what the renewal depends on, before a quarter is committed. Chapter two's discipline, applied inside a prioritisation decision. It costs one meeting.

What the answer probably is, and why "probably" is honest. Test the assumption first; if it holds, option 4. The interesting part is why option 1 is tempting anyway: it is legible. "We built what our largest customer asked for" is a sentence that survives any review, including one where the renewal was never actually at risk.

The cost, named. Option 4 means the customer is told they are getting something temporary, which is a harder conversation than saying yes, and someone has to own the replacement date or the flag becomes permanent — which is the most common way this ends.

Where it could still go wrong. The flag never gets removed and the "temporary" model becomes load-bearing, which is the failure mode of every temporary system ever built. Mitigation is a date and a named owner in the document, and even then the base rate is not encouraging.

Compute default alive or dead before debating strategy. Runway determines which arguments are admissible. Knowing the answer early converts a values argument into a constraints argument, and constraint arguments converge. Tell: the plan states runway and the profitability path, and its scope respects them. Absence in a resourcing debate is a strong negative signal.

Find the load-bearing assumption before writing the plan. Testing the riskiest one first means the plan either gets evidence or gets cancelled early, which is the cheapest possible outcome. Tell: present — an explicit list of what must be true, each marked evidenced or assumed. Absent — a risks section listing execution risks only.

Generate at least three options before choosing. A single-option proposal is a decision that already happened; the document is advocacy. Comparison is what makes a tradeoff visible. Tell: alternatives with their costs, including doing nothing. Beware the fake set: two strawmen flanking the intended answer.

Say what the chosen option costs. A proposal naming only benefits has either not found the cost or is hiding it, and the reader cannot evaluate it either way. Tell: an explicit "what we give up" — deferred work, the segment not served, the complexity added, the reversibility lost.

The single-option proposal

What it looks like. A memo recommending one course of action, with a risks section listing only execution risks. Alternatives are absent, or present as two obviously worse options flanking the intended answer.

Why smart people do it. Presenting options reads as indecision, and the author usually did decide — weeks ago, on instinct that may well be right. The document is written to transmit a decision, not to make one.

The correction. Require the real alternatives with their costs, including doing nothing. If the author is confident, the comparison costs them nothing and gives readers something specific to disagree with.

The costless tradeoff

What it looks like. A recommendation where every consequence is a benefit. The new approach is faster and cheaper and better for users and strategically superior. Nothing is given up.

Why smart people do it. Naming a cost invites attack on that cost. Advocacy culture punishes candour about downsides, especially in writing that will be read by people who fund things — so the incentive runs against the honest version at exactly the moment it matters most.

The correction. Ask what the option sacrifices and who bears it. A response that cannot name the cost has not understood the option well enough to choose it.

Runway denial

What it looks like. Ambitious multi-quarter plans, new headcount, and long payback bets at a company whose default-alive calculation has not been done — or was done and quietly ignored.

Why smart people do it. The calculation forecloses options the team is emotionally committed to, and there is always a plausible story about the next raise or the next big customer. Both of those things are usually true, which is what makes the story so easy to keep believing.

The correction. Compute it, state it at the top of the plan, and scope to it. The plan that respects the constraint is usually smaller and much more likely to happen.