Why a good product can be a bad business

Customers are happy, usage is healthy and reviews are positive. The founder opens the report and discovers that every new contract adds workload faster than profit. The team proposes better conversion and more traffic. First, though, it should understand exactly what it is about to scale.

A product delivers two different outcomes: it helps a person complete a task, and it earns the company enough to keep doing that work. The first does not automatically ensure the second. Between them sit price, acquisition cost, implementation, support and the duration of the customer relationship.

Start with one customer

Take a hypothetical procurement-approval service. The subscription is ₽12,000 a month. Infrastructure, document processing and support cost an average of ₽5,000 per customer, leaving ₽7,000 in monthly contribution before fixed costs.

Acquiring a paying customer costs ₽42,000 and implementation another ₽21,000: someone migrates reference data, configures routes and trains staff. Those costs do not disappear just because the founder does some of the work without invoicing themselves.

The final row divides 63,000 by 7,000. It assumes monthly payments, stable costs and no expansion or churn. It is a guide to a question, not a precise forecast: will this particular customer cohort return the money invested in it?

A healthy average can hide two different businesses

Suppose small teams launch themselves and rarely need support. Larger customers pay more but require a custom integration, security approval and regular changes. Blend them into one average sale and the economics looks tidy while decisions remain unclear.

Compare customers over the same horizon and with the same accounting rules. What belongs to acquisition? Where is implementation counted? How is support effort allocated? Has a one-off integration been paid for, or must its cost still be recovered? Without agreement, two departments can honestly calculate different versions of profit.

Unit economics is tied to segment and strategy choices: deciding whom to build for also determines how you sell, serve and earn.

Check which outcome the person pays for

A chain owner may need procurement approvals without constant calls to store managers. A finance lead may need payments kept within approved budgets. The same interface serves both jobs, but value, requirements and buying processes differ.

If the service is sold as a cheap request repository but needs expensive financial-control configuration, the problem may lie in the promise and service model. Raising everyone’s price by the same percentage is only one option. Others include charging separately for implementation, narrowing the scenario, standardising integration or choosing customers who need only the default configuration.

Each decision needs testing. A higher price may raise revenue per retained customer while lengthening the sales cycle. Self-service setup may lower costs but worsen activation. The economic model should show both effects.

Do not turn LTV into permission to spend

LTV estimates a customer’s value to the business over the relationship. For acquisition decisions, contribution is a useful basis, with the horizon and cost scope stated clearly. You cannot subtract full acquisition cost from lifetime revenue and call the difference profit.

For a young subscription business, lifetime has not yet been observed. A few months of good retention do not establish years of future payments. Keep actual accumulated cohort contribution alongside the forecast and scenarios for earlier churn, expensive support or lower pricing.

Even a customer who pays back needs financing. Sales and implementation money may go out today and return nine months later. Rapid growth can create a cash gap before accounting profit appears.

A decision for the coming week

Take the most recent completed implementations in one segment. Collect payments, sales costs, launch hours, support requests and repeat payments for each. Mark facts and forecasts separately.

Find the cost that most affects payback and that the team can actually influence. If it is manual implementation, the next product task may be a standard configuration. Success means less cost before first value without reducing the quality of that result. Economics then guides development before another feature enters the backlog.