Will a new product line pay back, and when?

The request usually comes from a good place. Customers keep asking for something adjacent to what the company already sells. Sales says it's losing deals without it. The product team has a design and an estimate. Somebody has worked out that if a fifth of existing customers bought it at the proposed price, it would add a meaningful percentage to revenue within a year.

That last calculation is where most new product lines are approved, and it's missing most of what decides whether they pay back. It counts revenue rather than contribution. It ignores the people cost of building and maintaining the product. It assumes adoption arrives quickly. And it doesn't ask what the new product does to the revenue the company already has.

Getting these right doesn't need a complicated model. It needs a few honest inputs and a willingness to look at the slow version. A spreadsheet with one row per month for three years is enough, and it's far more useful than a polished business case that only shows the year-one revenue.

Count the whole investment

Start with everything the company will spend before the product earns its first rupee, and be generous about what counts.

• ·The build team: engineers, designers and a product manager, at fully loaded cost, for the realistic number of months. Estimates for new products run long far more often than short.
• ·Anything bought: third-party services, data, licences, equipment or inventory.
• ·Launch costs: marketing, sales training, documentation, and pricing and packaging work.
• ·The people pulled from other work. If three senior engineers move off the core product for six months, what doesn't get built there has a real cost, even if it's not on an invoice.
• ·GST on inputs, for businesses that can't recover it.

Then add what it will cost to keep the product running after launch: a maintenance team, hosting, support, and ongoing marketing. Many product business cases stop at launch, as if the team that built it disappears afterwards.

Contribution, not revenue

The unit that matters is contribution per customer: what each customer pays, less every cost that grows with each customer. For software that's hosting and usage costs, third-party APIs, payment fees and the support each customer needs. For physical products it's cost of goods, packaging, delivery and returns. For services it's the time of the people delivering it.

A product with an attractive price and heavy variable costs can contribute very little. A product with a modest price and near-zero variable costs can contribute almost everything. Revenue projections hide the difference completely.

Cannibalisation and the halo

A new product rarely sells in isolation. Some of its revenue will come from customers who would otherwise have spent the same money on something you already sell. A cheaper tier pulls customers down from a more expensive one. An add-on bundled at a discount replaces a full-price purchase. A new location takes customers from an existing one nearby.

The opposite also happens. A new product can make the core product more valuable, reduce churn, or open doors to customers who then buy both. That's the halo, and it's real, but it's much harder to measure and much easier to overstate.

The honest approach is to estimate both, and then give the halo less weight in the decision than cannibalisation, unless you have evidence from past launches.

A payback curve, worked through

Here's an illustrative example with invented figures. A B2B software company wants to build an analytics add-on for its existing customers.

Building it takes five engineers six months at about ₹2.1 lakh a month each, fully loaded: ₹63 lakh. Launch marketing and sales enablement add ₹12 lakh. The total investment before launch is ₹75 lakh.

The add-on will sell for ₹6,000 a month per customer. Data infrastructure and extra support cost about ₹1,500 a month per customer, so each one contributes ₹4,500. After launch, two engineers stay on to maintain and improve it, at ₹4.2 lakh a month. The team estimates 30 customers in the first month and 25 more each month after that, with about 2% of add-on customers cancelling each month.

One more thing. The sales team expects about one in ten add-on buyers to downgrade their main subscription, because the add-on covers something they used a higher tier for. That costs ₹3,000 a month for each downgrading customer, or about ₹300 a month averaged across all add-on customers.

Put that together month by month. Six months after launch the add-on has about 147 customers and contributes around ₹2 lakh a month after maintenance and cannibalisation, but the cumulative position is still about ₹78 lakh negative, slightly worse than at launch, because the early months didn't cover the maintenance team. By month twelve there are about 273 customers, contributing roughly ₹7.3 lakh a month, and the cumulative position has improved to about ₹47 lakh negative.

The add-on pays back in about month 17 after launch. Counting the six months of building, that's close to two years from the decision to the point where the company is ahead.

Now halve the adoption

The inputs that most often turn out wrong are the adoption ones. Customers who asked for a feature in a sales call don't all pay for it when it exists. So run the same model with half the customer additions: 15 in the first month and 12 or 13 each month after.

In the example, the add-on is still about ₹86 lakh behind after a year, only reaches positive monthly contribution of around ₹6 lakh by the second year, and pays back in about month 30 after launch, three years from the start of building.

That doesn't mean don't build it. It means the question isn't whether the add-on pays back. It's whether the company can afford a three-year payback if adoption is slow, and whether it would still choose this over the other things the same engineers could build. If the answer to the slow case is no, the base case isn't a safe basis for approval either.

The same logic outside software

The example is a software add-on, but the method works for any business adding a line.

A restaurant brand launching a breakfast menu or a second cuisine counts the kitchen equipment, recipe development, staff training and launch marketing as the investment. Contribution per order comes after food cost, packaging, and aggregator commission with the GST on it. Cannibalisation is customers ordering the new item instead of an existing one with a better margin. The ramp is orders per day, which usually starts strong on novelty, dips, and then settles.

A healthcare business adding a new service line, say diagnostics alongside consultations, counts equipment, licences, trained staff and the GST it can't recover on inputs. Contribution per test comes after consumables, reporting costs and any referral fees. The halo is real here, because patients who get tests on site often return, but it should be measured from actual repeat visits rather than assumed.

A services firm adding a new practice counts the senior hires and the months they spend building a pipeline before they bill. Contribution is billable hours at realised rates, less the delivery team's cost. Cannibalisation is existing clients moving budget from one service to the other. The ramp is almost always slower than the business case, because clients rarely buy a new kind of work from a firm until someone they trust inside it has done that work well.

Mistakes that show up in product business cases

• ·Using revenue run rate as the measure of success instead of cumulative contribution.
• ·Stopping the costs at launch, as if the build team disappears.
• ·Treating existing staff time as free because they're already on payroll.
• ·Counting every customer who asked for the product as a future buyer.
• ·Ignoring customers who will downgrade or switch.
• ·Presenting only the base case, so nobody sees what slow adoption looks like until it happens.
• ·No agreed measure or date for deciding whether to keep investing.

Questions to ask before approving

• ·What's the build estimate based on, and how accurate were the team's last three estimates?
• ·What does each customer really contribute after every variable cost?
• ·How many customers who asked for it have agreed to pay for it, in writing or with a pre-order?
• ·Which existing revenue will it replace, and how much?
• ·Who maintains it after launch, and what do they stop doing?
• ·When does it pay back at the planned adoption rate, and at half of it?
• ·What would the same team build instead, and what's that worth?
• ·What will we measure at three and six months to decide whether to keep investing?

The third question is often the most revealing. Customers are generous with enthusiasm in sales conversations and much more careful with money. A handful of committed early buyers, even at a discount, is worth more than a long list of people who said it would be useful.

Fund it in stages

Instead of approving the whole build at once, many companies do better approving it in stages, each with a test that has to be passed before the next stage is funded.

1. 01A small version, built by a small team in a short time, offered to a limited group of customers.
2. 02A test: a minimum number of paying customers, a minimum usage level, and early retention above a set bar.
3. 03If the test is met, the full build and launch. If it isn't, a decision to change the product, the price, or stop.

Staging costs a little speed. It saves a great deal when the idea turns out to be weaker than it looked, and it gives the team working on it a clear bar to aim for instead of an open-ended bet.

What to track after launch

Once the product is live, track it separately from the core business every month: customers, contribution per customer, cumulative investment, cumulative contribution, and the cannibalisation you can observe, such as downgrades and switched purchases. Compare actual adoption against the base case and the half-speed case you modelled before approval.

If the product is tracking the slow case after six months, that's the moment for a clear decision rather than another quarter of hope. Having the payback curve from the original approval makes that conversation factual instead of personal.

The short version

Count everything it costs to build and maintain. Use contribution, not revenue. Subtract what it replaces. Draw the cumulative curve. Halve the adoption and draw it again. If the company can live with the slow curve, and nothing better is competing for the same people, build it, preferably in stages. If it can't, the product may still be a good idea, but not yet, or not in this form.

Who wrote this

Shafneed is the founder of Simplify, a finance clarity and investment readiness practice working with founders across India. He writes about the questions founders bring before a decision, not after it.