Your product is money

When it comes to money, ignorance is NOT bliss. What you don't know CAN hurt you.

S. Simmons — "Unleash Your Cash Flow Mojo"

Over twenty years, the product craft has developed a remarkably rich vocabulary for talking about people. We have words for context, for intention, for frustration, for the progress somebody is seeking. We can argue for an hour about whether something is a need or a desire.

For talking about money, however, we remain nearly mute. It is common to find people running products who can explain the Jobs To Be Done framework with precision and cannot explain the difference between revenue and margin, or what happens to their company's income statement when they decide to add a feature that makes three model calls per interaction.

That imbalance is not an academic gap. It is why many product people are left outside the conversations where what can be built gets decided, and only receive the outcome in the form of a cut.

Everything you decide comes with an invoice

Building a feature consumes capital that had alternative uses. The sentence looks obvious and yet it almost never appears in prioritisation discussions, which get settled with impact and effort as if effort were an abstract magnitude rather than a number of people drawing a salary for several weeks.

There are two minimum literacies that noticeably change the quality of decisions.

The first is understanding what a customer costs and what a customer yields. Not as a figure on a slide, but as a structure: how much it costs to acquire them, how long it takes to earn that back, how much it costs to serve them each month, how long they stay. Once those four numbers are in your head, many product arguments resolve themselves, and some initiatives that looked strategic turn out to consist of losing money faster.

The second is understanding the difference between being profitable and having cash. It is exactly what the quotation says: ignorance about money protects you from nothing. A company can have healthy margins and die because it invoices at ninety days and pays at thirty. And that asymmetry, which looks like an administrative matter, decides very concrete product things: whether annual or monthly billing makes sense, whether the free plan can exist at all, how long you can afford to take before the first invoice from a large customer is paid.

The crack in marginal cost

There is one economic fact on which all modern software was built: serving one more user cost effectively nothing. From that came flat pricing, free accounts, growth without cost growing alongside usage, and an entire industry that could afford not to look at variable cost for two decades.

That fact has cracked. Inference costs money per request, and the cost depends on how much text goes in, how much comes out and which model is used. Which is to say, it depends on product decisions made by people who often do not know they are making cost decisions. A change in the size of the context you send is a margin decision dressed up as a technical detail.

This puts back on the table questions software had managed to forget. How much usage is included. What to do about the customer consuming twenty times the average. Whether flat pricing still makes sense when cost does in fact vary. These are not finance questions: they are product design questions answered in financial vocabulary.

The danger in the opposite direction

The other side deserves saying too, because correcting one blind spot usually produces its symmetrical twin.

An organisation that only talks about money builds bad products. It is the familiar trap: when the only available language is quarterly revenue, everything that cannot be attributed to quarterly revenue disappears from the plan, and what disappears first is always whatever sustains the product three years out. Technical debt, research without immediate results, fixing the things that already work badly enough to tolerate.

Understanding money is not submitting to money. It is ceasing to be the person to whom the budget is explained and becoming one who can argue about it. That is the difference between receiving a constraint and taking part in the conversation where the constraint is set.

What you do not know about your product's money does not leave you alone. Somebody simply decides it in your place.