Two products sit beside each other. One costs $8. The other costs $11. The first one looks cheaper. That conclusion may be correct. Or it may be completely wrong. If the first contains 500 grams and the second contains 1 kilogram, the more expensive package actually gives you more for each dollar. The total price was accurate. The comparison was not. This is a small example of a much larger idea: The number we see first is not always the number we should compare. Good decisions often begin by choosing the right unit.
Total Price Is Only One Dimension
Price is useful because it is visible. It gives us something concrete to compare. But a total price answers only one question:
It does not automatically answer:
Those are different questions. A larger package may cost more but cost less per unit. A subscription may look inexpensive per month but expensive per actual use. A server may have a higher monthly cost but support far more workloads. A machine may cost more to purchase but less to operate. A project may require more effort initially but reduce recurring work for years. The total matters. But without context, totals can mislead.
Find the Denominator
Many better comparisons are created by a denominator. Instead of asking:
we ask:
Per kilogram. Per liter. Per user. Per transaction. Per hour. Per kilometer. Per usable watt-hour. Per successful outcome. Per month of expected service. The denominator turns an isolated number into a rate. Rates are often more useful because they allow unlike totals to be compared on a shared basis. For example: A 750 ml bottle costs $3. A 1.5 liter bottle costs $5. Looking only at the shelf price, $3 feels cheaper. Normalize them:
- first bottle: $4 per liter
- second bottle: about $3.33 per liter
Now the difference becomes clearer. The calculation is simple. Choosing to perform it is the more important step.
The Right Unit Depends on the Decision
There is no universally correct denominator. The right unit depends on what you are trying to decide. Suppose two internet plans are being compared. Price per month may be enough if both services are identical. But perhaps they are not. You might need to compare:
- price per Mbps,
- usable monthly data,
- expected uptime,
- installation cost,
- latency,
- or effective cost over the full contract period.
Each unit reveals something different. A low price per Mbps may still be poor value if the connection is unreliable. A higher monthly price may be reasonable if the service replaces another expensive workaround. Measurement should therefore begin with the purpose of the decision. This connects directly to an earlier principle in this series: Define the purpose before you build the tool. The same applies to metrics. Define the decision before you choose the measure.
Normalize Before Comparing
In data analysis, this process is often called normalization. The idea is simple: bring different things onto a comparable scale. Imagine two teams. Team A closes 100 support tickets. Team B closes 60. At first glance, Team A appears more productive. But suppose Team A has 10 people and Team B has 4. Now look at tickets per person:
- Team A: 10
- Team B: 15
The story changes. That does not automatically mean Team B is “better.” Ticket complexity may differ. Working hours may differ. Quality may differ. But the normalized measure exposes something the raw total hid. This is why totals are often useful for describing size, while rates are often better for comparison.
A Metric Can Be Correct and Still Be Misleading
This is closely related to yesterday’s idea that zero is not the same as missing. A number can be technically correct while encouraging the wrong interpretation. Suppose a project costs $20,000. Is that expensive? There is no meaningful answer yet. For what? For one small feature? For a platform used by 50,000 people? For a system expected to operate for ten years? For infrastructure that replaces $5,000 of annual recurring cost? The total cost is real. But whether it is high or low depends on scale, duration, alternatives, and outcomes. The number needs a frame. Without one, we risk treating magnitude as meaning.
Unit Price Is Not Always Enough
There is another trap. Once we learn to use unit price, we may begin treating it as the final answer. It is not. A large package may have a better price per kilogram but still be a worse purchase if much of it will be wasted. A cheap subscription per user may be poor value if hardly anyone uses it. A large battery may have a good cost per amp-hour but poor cycle life. A server may have a low cost per gigabyte but high power consumption. The unit itself must correspond to usable value. This creates a deeper question:
Sometimes it is not the unit printed on the label.
Measure What You Actually Consume
Suppose one food package contains 2 kilograms. Its unit price is excellent. But a household can use only half before the rest spoils. The effective cost per consumed kilogram is now much higher. The nominal unit and the useful unit are different. The same thing happens in technology. A software plan includes 100 seats. Only 40 are used. The advertised cost per seat is based on 100. The effective cost per active user is based on 40. Infrastructure provides 10 terabytes of storage. Only 2 terabytes are needed. The headline storage rate may be cheap, but unused capacity still has a cost. This is why useful measurement should reflect reality, not merely contractual capacity.
Cheap Can Be Expensive
Unit thinking also helps expose recurring cost. Imagine two pumps. Pump A costs $120. Pump B costs $180. If we stop at purchase price, Pump A wins. But suppose Pump A consumes more electricity and needs replacement after two years. Pump B consumes less power and lasts five years. Now the relevant unit might be: cost per year of useful service or perhaps: total lifecycle cost per cubic meter pumped The original price still matters, especially when cash is limited. But it no longer tells the whole story. A lower initial price can create a higher total cost. This is one reason procurement based only on purchase price can produce poor outcomes.
Time Is a Unit Too
One of the most useful units in knowledge work is time. Suppose a manual task costs nothing financially. It takes 15 minutes every day. That sounds small. Over a year: 15 minutes × 365 days = 5,475 minutes. That is more than 91 hours. The “free” process consumes more than two full workweeks. Now suppose automation takes eight hours to build. The question changes. Instead of:
we can ask:
That is a much better question. The unit reveals the recurring structure hidden inside the small daily cost.
Frequency Changes Value
This is why frequency matters. A problem costing five minutes once a year is probably not worth engineering around. A problem costing five minutes 100 times every day may deserve immediate attention. The cost per event is identical. The system-level cost is not. A useful formula is often: cost per occurrence × number of occurrences This sounds obvious when written down. Yet many prioritization mistakes happen because one side of that equation is ignored. We notice the inconvenience. We do not measure repetition. Or we notice frequency without measuring impact. Good prioritization often requires both.
Compare Alternatives on the Same Basis
Another common mistake is comparing alternatives using different frames. Suppose one option is described by purchase cost. Another is described by monthly cost. A third is described by cost after discounts. Without normalization, the comparison is unstable. For example: Option A: $1,000 upfront. Option B: $95 per month. Which is cheaper? We need a timeframe. Over one year:
- A: $1,000
- B: $1,140
Over three years:
- A: perhaps still $1,000, assuming no major ongoing costs
- B: $3,420
The preferred option may still depend on cash flow, risk, maintenance, and flexibility. But at least the numbers now live on the same axis. A comparison requires a common frame.
Be Careful With the Denominator
Denominators are powerful. They can also manipulate. Suppose a company says:
That sounds smaller than:
Both are mathematically equivalent. But they create different psychological impressions. Similarly:
may sound trivial until the process runs 10 million times. This is why we should be cautious whenever a metric has been normalized for us. Ask: Why was this denominator chosen? Would another unit reveal something important? What happens when I scale it back to the total? Good analysis moves comfortably between totals and rates. Neither should hide the other.
The Same Principle Applies to Performance
Consider software performance. Suppose one process handles 1 million requests. Another handles 500,000. Again, raw totals tell us scale. But for comparison, we may want:
- requests per second,
- average response time,
- CPU time per request,
- memory per transaction,
- error rate per thousand requests,
- cost per successful request.
Each reveals a different property of the system. This is why serious performance analysis rarely depends on one headline number. A system is multidimensional. Good metrics isolate the dimension relevant to the question.
Financial Decisions Need Units Too
Personal finance benefits enormously from this thinking. Imagine comparing two sources of electricity. One appears cheaper because its initial equipment cost is lower. A more useful comparison might consider:
- cost per kWh delivered,
- battery replacement cycles,
- fuel costs,
- maintenance,
- expected service life,
- downtime,
- conversion losses.
The decision may still be constrained by what is affordable today. That matters. But knowing the lifecycle unit cost helps distinguish: what I can afford now from what costs less overall. Those are two valid but different questions. Good decisions become easier when we stop forcing them into one number.
Measure Outcomes, Not Just Inputs
Perhaps the most important shift is from measuring inputs to measuring outcomes. Suppose two training programs cost:
- Program A: $500
- Program B: $800
We can compare cost per hour. Useful. But perhaps what matters is cost per person who successfully acquires the required skill. Now imagine:
- Program A trains 20 people, 5 reach competencies.
- Program B trains 20 people, 16 reach competencies.
The cheaper program costs: $100 per successful outcome. The more expensive program costs: $50 per successful outcome. The higher total cost produced better unit economics relative to the desired result. That is a much more meaningful comparison.
Sometimes the Unit Is Hard to Measure
Of course, not everything important can be neatly divided. What is the unit value of trust? Resilience? Better architecture? A prevented failure? A clearer decision? Some outcomes are difficult to quantify. That does not mean they are worthless. It means quantitative measurement should not pretend to capture more than it can. We can use numbers where they clarify. We can use qualitative judgment where the important variables resist reduction. The mistake is not failing to turn everything into a unit. The mistake is using an easy unit as a substitute for the real objective.
Choose the Unit Before Optimizing
Once a system begins optimizing a metric, the metric becomes influential. If we optimize for tasks completed, people may select easy tasks. If we optimize for cost per unit without quality, quality may fall. If we optimize for response time without correctness, systems may become fast and wrong. If we optimize for output per hour, difficult but important exploratory work may appear inefficient. Measurement is not passive. It changes behavior. That means choosing a unit is also choosing what the system will encourage. This deserves more thought than simply selecting whatever number is easiest to collect.
A Simple Comparison Habit
When faced with two alternatives, I find a small sequence useful. First: What am I actually trying to optimize? Cost? Durability? Time? Capacity? Outcome? Reliability? Then: What unit best represents that objective? Next: Can both alternatives be expressed using that same unit? And finally: What important dimensions disappear when I reduce the decision to this unit? That final question protects us from becoming too confident in a single metric. The goal is not mathematical elegance. The goal is clearer judgment.
From Data to Decisions
Over the last few articles, a pattern has been emerging. Choose the right task. Define the purpose before building the tool. Design the workflow to survive interruption. Preserve the difference between zero and missing. Now: choose the right unit before making the comparison. These ideas share a common foundation. Meaning comes before optimization. If the task is wrong, speed does not help. If the purpose is unclear, more features do not help. If state is lost, activity does not guarantee progress. If missing data becomes zero, precise calculations do not create truth. And if the unit is wrong, better arithmetic does not create a better decision.
The Number Needs a Question
These ideas share a common foundation. Meaning comes before optimization. If the task is wrong, speed does not help. If the purpose is unclear, more features do not help. If state is lost, activity does not guarantee progress. If missing data becomes zero, precise calculations do not create truth. And if the unit is wrong, better arithmetic does not create a better decision.
The Number Needs a Question
Numbers are powerful because they compress complexity. But that compression can hide context. A price needs a quantity. A total needs a scale. A rate needs a denominator. A cost needs a timeframe. A performance metric needs a workload. An investment needs an expected useful result. Before comparing numbers, ask what question they are supposed to answer. Then choose the unit that makes the answer meaningful. Because $8 is not necessarily cheaper than $11. Five minutes is not necessarily a small cost. One thousand dollars is not necessarily expensive. And a larger number is not necessarily worse. The measure becomes useful only when the unit matches the decision. Measure the unit, not just the price.