Economics: one currency for every trade-off

Choose between actions by their quantified effect on overall economics, not by their effect on a single proxy goal.

Proxies like 'hit the date', 'cut unit cost' or 'stay on budget' conflict with each other, and only money lets you add them up. Build a simple life-cycle profit model and ask how much each option moves it.

You cannot change one variable in isolation; every action shifts several economic variables at once.

Adding a feature raises value but also adds schedule, expense and risk. Express all the side effects in the same unit so the trade-off is visible instead of argued.

If you quantify only one thing, quantify the cost of delay.

Cost of delay drives queue sizes, batch sizes, priorities and how much you should pay to go faster, yet Reinertsen found about 85% of product developers do not know it, and gut estimates for the same project varied 50:1. A rough number beats a confident feeling.

An activity adds value only to the extent that it raises the economic value of the work product.

Value-added is measured by what a buyer would pay for the design after the activity versus before it. A test that removes a large risk can add more value than weeks of coding, and work that changes nothing about expected profit adds none.

Watch the work product, not the worker: queued work, not idle people, is where most waste hides.

In development, inventory is invisible design-in-process. When every engineer is busy, the work product spends most of its life waiting in queues, and that waiting is pure cost of delay.

Important trade-offs usually have U-shaped total-cost curves with an interior optimum.

When one cost rises and another falls with the same choice (batch size, test effort, decision timing), the total has a minimum in the middle. Extremes are rarely optimal.

Even imperfect answers improve decisions; the flat bottom of a U-curve forgives estimation error.

Being 50% off the optimum on a U-curve typically costs only a few percent. So a rough cost-of-delay estimate is enough to move decisions in the right direction — waiting for precision is the expensive option.

Most economic value is decided by the many small decisions, so influence those rather than only the few big ones.

Hundreds of daily trade-offs by engineers outweigh a handful of executive gate decisions. Equip the people making them with economic decision rules.

Economic choices must be made continuously as new information arrives, not once at the start of a project.

The right trade-off shifts as markets, costs and risks change. A plan fixed at kickoff locks in yesterday's economics; a decision rule lets the team re-decide every day.

Many economic choices are more valuable when made quickly; their value decays while they wait.

An opportunity to save two weeks of schedule is worth nothing if approving it takes two weeks. Fast, local decisions capture value that escalation lets rot.

Inside every bad choice lies a good choice: decompose an option and keep its good parts.

A feature that loses money as a whole often contains sub-features with high value per cost. Splitting it and keeping only those turns a rejection into a profitable decision.

Build a system that captures the cheap economic opportunities early, before they disappear.

Early in a project, schedule and cost can be traded cheaply; later the same trade is expensive. Pre-authorize small trades (e.g. 'spend up to $X to save a week') so engineers can harvest them the moment they see them.

Use economic decision rules to decentralize control without losing economic alignment.

A rule like 'a week of delay costs $150k' lets anyone make a correct trade-off without a meeting. Boeing's 777 program let engineers trade up to about $300 of unit cost per pound of weight saved.

Make sure decision makers feel both the cost and the benefit of their choices.

A team charged for expense but never for delay will always save budget and lose schedule. Pricing scarce resources and delay makes local choices match global economics.

Every decision has an economically optimal moment; neither as early nor as late as possible is right by default.

Deciding early is cheap to execute but uses poor information; deciding late uses better information but costs more to change course. The total forms a U-curve with an optimum you can reason about.

Always compare marginal value with marginal cost, not totals or averages.

Keep improving a feature only while the next increment of value exceeds the next increment of cost (including cost of delay). The optimum is where the two marginal curves cross, usually well before 'complete'.

Ignore money already spent; only future costs and benefits matter to a decision.

Whether a project has burned $1M or $10M, the question is the same: does the remaining spend buy more value than it costs? Past spend explains history but cannot change the comparison.

Information is worth what it changes in expected economic outcome; buy it when it costs less than that.

A prototype or test is valuable only if its result could change a decision. Information is worth most when uncertainty is highest and the stakes are large, and cheap early information is the best buy.

Don't pay more for insurance than the expected loss it prevents.

Parallel backup solutions are insurance against a technical failure. Add another path only while its cost is less than the reduction in expected loss it buys.

A high probability of failure does not imply bad economics when the payoff is asymmetric.

Like a newsboy stocking papers, judge an option by expected value, not by its odds. A bet that fails 90% of the time but returns 20× on success is a good bet, especially in a portfolio.

To influence financial decisions, speak the language of money.

Executives who control resources respond to dollars, not to cycle-time charts. Translate 'we'll be three weeks late' into '$450k of lost life-cycle profit' and the conversation changes.