The unit economics reckoning

The most celebrated startups of the cheap-capital era had something in common. Extraordinary growth rates. Enormous user bases. And, in a remarkable number of cases, no coherent explanation for how they would ever make more money than they spent acquiring each customer.

That was the paradox. Growth was the proof of value. Growth was also the mechanism by which value was destroyed.

Nobody talked about this when the money was flowing. Venture capital was cheap, rounds were large, and the implicit contract was simple: grow now, figure out the economics later. Later turned out to be a specific moment. The moment when interest rates went up, funding tightened, and finance teams started asking questions that product teams had never needed to answer.

Why this matters to product people

There's a common assumption in product teams that unit economics belong to finance. That CAC, LTV, payback periods, and margin calculations are someone else's spreadsheet. Product people build the thing. Finance people figure out whether the thing makes money.

But this is a structural misunderstanding of how products actually work.

Every product decision is a unit economics decision. The onboarding flow that takes four days instead of one is a CAC decision (it costs more to convert a user who takes four days to understand the product). The feature that increases daily active usage but doesn't connect to any monetisation event is an LTV decision (engagement without revenue is just server cost with better optics). The pricing tier that's too cheap to justify sales involvement but too expensive for self-serve is a margin decision hiding inside a pricing page.

Product teams that don't understand this aren't just leaving money to someone else. They're making commercial decisions without knowing it. Which is worse.

The denominator problem

At my first startup, we had a dashboard that everyone loved. Users acquired this week. Users acquired this month. The graph went up and to the right. It was the kind of chart you put in an investor update. It felt like progress.

But nobody had built the other dashboard. The one that showed what each of those users cost to acquire. The one that showed what each of them was worth over time. The one that divided revenue by the number that mattered, not the number that felt good.

I call this the denominator problem. Every product team has a numerator they celebrate. Users. Downloads. Sign-ups. Active sessions. But the denominator, the cost of acquiring each one and the revenue each one generates, is invisible until someone forces it onto the screen.

We didn't force it onto the screen until month fourteen. By then we'd burned through most of our runway celebrating a numerator that was growing while the denominator was eating us alive. We had ten thousand users. Our cost to acquire each one was roughly four times what they'd ever pay us. Growth without unit economics is a story you tell yourself until the money runs out. Ours ran out on a Tuesday. The bank balance was the punchline nobody laughed at.

A farmer who measures crop yield by the number of seeds planted, not by the harvest, would be bankrupt in two seasons. We were that farmer. We just had better graphs.

The growth mirage

The first startup taught me what happens when you don't know your economics. Adobe taught me what happens when an organisation treats them as sacred.

At Adobe, every feature had a commercial case attached to it before it entered the roadmap. Not a vague "this will improve retention" claim. A specific argument: this feature will reduce churn by X percent in this segment, which translates to Y dollars retained over Z months. If the math didn't hold, the feature didn't get built. Full stop.

I found it frustrating at first. It felt like the finance team was standing between design and the user. But over time, I saw what it actually produced. Discipline. Not every feature needed a direct revenue line. But every feature needed someone who could articulate why it was worth the cost of building and maintaining it. That's a different question from "is this a good idea," and it's a harder question. It's also the right one.

The growth mirage is what happens when teams answer the easy question and skip the hard one. Is this a good feature? Yes. Will users like it? Probably. Does it move a commercial metric that matters to the survival of this business? Silence.

I've sat in roadmap reviews at three different companies where nobody in the room could connect a single planned feature to a specific revenue outcome. Not because the features were bad. But because the habit of asking had never been built. The culture rewarded shipping. Nobody had thought to reward shipping things that made the business work.

The how: three numbers every product person should know

You don't need a finance degree. But you need to know three numbers for your product.

The first is your acquisition cost. Not the marketing budget divided by sign-ups. The fully loaded cost: marketing, sales, onboarding support, the engineering hours spent on the acquisition funnel, the time your PM spent writing copy for the landing page at midnight. All of it. Most product teams undercount this by 40 to 60 percent because they only count what marketing spends.

The second is your customer lifetime value. Not a projection based on the assumption that every user stays for three years. The actual, observed value of a customer over the time they've actually been a customer. Early-stage companies often don't have this number because they haven't existed long enough. But the honest estimate, with assumptions stated clearly, is better than the fiction of "we assume 36-month retention" when the product has been live for nine.

The third is the ratio between them. If it costs you more to acquire a customer than that customer will ever pay you, you do not have a business. You have a mechanism for converting investor money into user growth. Those are different things, and the difference matters when the investor money stops.

What changes when you know

Knowing your unit economics doesn't constrain creativity. It redirects it. The product team that knows acquisition cost is too high starts thinking about viral loops, referral mechanics, and onboarding that converts faster. The team that knows LTV is too low starts thinking about expansion revenue, usage depth, and the features that make someone stay for month thirteen instead of leaving at month six.

But the team that doesn't know either number builds whatever feels right and hopes the spreadsheet works itself out. Hope is a fine personal quality. It is a terrible commercial strategy.

The reckoning that arrived when capital tightened wasn't a surprise to anyone who understood their own numbers. It was only a surprise to teams that had never looked at them. And the uncomfortable truth is that many product teams, filled with genuinely talented people, had simply never been asked to.

That's the part I keep coming back to. Not that product people failed at unit economics. But that nobody thought to teach them. The finance team assumed product understood. Product assumed finance had it covered. And in the gap between those two assumptions, entire companies burned through their runway building things that users loved and the business couldn't afford.

If you're early in your career and none of this was part of your training, that's not your fault. But it's your problem now. The good news is that the math isn't hard. The discipline is. And discipline, unlike capital, is something you can build for yourself.