When should you stop a product that isn't working?

Eighteen months ago the company launched a second product. The logic was sound: existing customers kept asking for it, a competitor had something similar, and the team that built the core product had capacity. Six people work on it now. It brings in about 9% of revenue. Every quarterly review ends in the same place: adoption is slower than hoped, but the next release will fix the onboarding, a big customer is close to signing, and it's too early to judge.

Nobody in that meeting is being dishonest. The product's champions genuinely believe it, and some of them may be right. But a company can spend years in that loop, and the cost isn't only the money. It's the six people who could be working on the thing that's actually growing, and the founder's attention every time the question comes back.

Knowing when to stop is one of the most valuable judgements a founder makes, and one of the least practised.

Why stopping is so hard

The reasons are mostly human, which is exactly why a financial frame helps.

• ·Sunk cost. Eighteen months of work feels like an investment that stopping would waste, even though it's spent either way.
• ·Identity. The product was often the founder's idea, or a senior hire's reason for joining. Stopping it can feel like a verdict on a person.
• ·The team. People built it and believe in it. Stopping means difficult conversations and, sometimes, losing good people.
• ·Customers. A few really do love it, and they'll be unhappy.
• ·The investor story. The product may be in the deck as a second growth engine.
• ·The next quarter. There's always a plausible reason the numbers are about to turn.

None of these is irrational. But none of them answers the actual question, which is whether the company is better off putting its limited people and money somewhere else.

That question is easier to answer with numbers on the table, because numbers give everyone in the room, including the product's strongest supporters, the same thing to argue about. Without them, the loudest voice or the most senior sponsor tends to win, and the product survives another quarter by default.

Build the product's own P&L, honestly

Most companies can't answer that question because they've never separated the product's numbers. Revenue might be tracked separately, but costs sit in shared lines: engineering, hosting, support, marketing. So start by building a P&L for the product alone.

• ·Revenue from the product, net of discounts, including any bundled revenue fairly allocated.
• ·Direct costs: hosting, third-party services and APIs, payment fees, and anything else that exists only because the product does.
• ·Dedicated people, at fully loaded cost: the engineers, the product manager, the support person who spends most of their time on it.
• ·Marketing and sales spent specifically on it.
• ·A share of the costs it uses but doesn't own: part of the platform team, part of customer success, part of the office.

Keep that last category visibly separate from the rest. The whole decision depends on distinguishing costs that would go away if the product stopped from costs that would stay.

The costs that matter are the ones that go away

Here's an illustrative example, with invented figures. A software company's second product brings in ₹14 lakh a month. Direct costs are ₹5 lakh. The dedicated team of six costs ₹9.5 lakh a month fully loaded. Allocated shared costs, for platform engineering, customer success and overheads, come to ₹4 lakh.

On a fully allocated basis, the product loses ₹4.5 lakh a month. That's the number that usually gets quoted in the meeting, and the product's champions rightly point out that the shared costs wouldn't disappear if the product stopped.

They're correct. So look only at avoidable costs: the ₹5 lakh of direct costs and the ₹9.5 lakh team. Against ₹14 lakh of revenue, the product loses about ₹50,000 a month on the costs that would actually go away. It's close to paying for itself, but not quite.

That changes the conversation. Stopping it saves about ₹50,000 a month, not ₹4.5 lakh, because ₹4 lakh of shared cost stays behind and now has to be carried by the core product. If that were the whole story, the case for stopping would be weak.

It isn't the whole story, because of the second number that matters: what those six people would do instead. If moving three engineers to the core product would ship features customers there are waiting for, or bring a new plan tier forward by two quarters, the value of that work belongs in the comparison. It's usually much larger than the saving.

Is it actually improving?

A product that loses money today can still be worth backing if it's clearly on the way somewhere. The trouble is that revenue growth is a poor way to tell. A product can grow revenue steadily by acquiring customers expensively who then leave.

Look instead at the numbers that show whether each new customer is worth more than the last. Retention by monthly cohort: are customers who joined recently staying longer than those who joined a year ago? Contribution per customer after the costs of serving them. Payback on acquisition cost. Usage among the customers the product was designed for.

If those lines are improving quarter after quarter, even slowly, there's a real case for patience with a defined horizon. If they've been flat for three or four quarters while the team explains why the next one will be different, that's the pattern of a product that isn't going to get there on its current path.

Set the test before the review

The single most useful thing a founder can do is agree, in advance and in writing, what the product needs to show and by when. For example: by the end of the second quarter, contribution after avoidable costs is positive, and at least 40% of customers who joined in the quarter are still active after three months. If both are met, the product gets another two quarters of investment. If neither is, it stops or changes shape. If one is, the leadership team decides, using a short list of options agreed now.

Setting the test early does three things. It forces the team to agree which numbers matter before anyone knows the answer. It gives the product a fair and clear chance, which is better for the people working on it than a vague sense of being on probation. And it takes the decision away from whoever happens to argue most persuasively in the review.

The test has to be realistic. A bar nobody could meet is just a slow way to stop. But it has to be a real bar, with a real consequence.

The options between keeping and killing

Stopping outright isn't the only alternative to carrying on as before, and often isn't the best one.

• ·Reprice. Some products fail on price rather than value. A higher price with fewer, better customers can turn the unit economics round.
• ·Narrow. Focus on the one customer segment where retention is strong and stop trying to serve the rest.
• ·Fold it into the core product as a feature or a higher tier, where it adds value without needing its own team.
• ·Freeze investment. Keep it running for existing customers with minimal maintenance, and move the team.
• ·Sell or license it to a company for whom it's a better fit.
• ·Sunset it with notice, a migration path for customers and honest communication.

Each has a different cost and a different effect on customers and the team. It's worth modelling the two or three most realistic options side by side, with the same avoidable-cost logic, rather than debating keep or kill in the abstract.

Stopping well

If the answer is to stop, how it's done matters almost as much as the decision. Customers deserve notice in line with their contracts, and a clear path: migration to the core product, a refund of prepaid amounts where it's owed, or help moving elsewhere. Read the contracts first, because some will carry commitments about notice or service levels.

The team deserves to hear it from the founder, with the reasons, before anyone else. Where people can move to other work, say so clearly and quickly. Where roles are ending, handle it properly and generously within what the company can afford, and model the cash cost of doing so before announcing anything.

The accounts need attention too. Development costs that were capitalised may need writing off, and prepaid revenue may need refunding. Your auditor will ask. And investors should hear about it from you, framed as a decision about where the company is putting its resources, not discovered in the next MIS.

What investors actually think when you stop something

Founders often worry that stopping a product will look like failure to their investors. Experienced investors tend to see it differently. They've watched many companies spread a small team across too many bets, and they know how rarely the struggling one turns round.

What worries them isn't a product being stopped. It's a product being kept alive long after the numbers said otherwise, because it suggests the company can't make hard decisions. A founder who comes to a board meeting with the product's honest P&L, the test that was set, the result, and a clear plan for where the people and money go next is showing exactly the judgement investors hope they backed.

The same framing works for the team. Stopping a product is a decision to focus, and saying so plainly, with the reasons, is far better than letting people guess.

A note from experience

Shafneed co-founded a startup in 2020, tested demand and the cost structure, and stopped it when the economics didn't hold. The lesson that carried forward wasn't about the spreadsheet, which made the answer fairly clear. It was about how different the same numbers feel from inside, where every month brings a new reason to believe the next one will be better. That's why the test has to be written down while everyone is still optimistic.

What to do this month

1. 01Build the P&L for any product line that's been 'about to turn' for more than two quarters, separating avoidable costs from shared ones.
2. 02Chart retention by cohort and contribution per customer for the last four quarters.
3. 03Write down what the people on it would do if they moved, and what that would be worth.
4. 04Agree a test, a date and the options with your leadership team, before the next review.
5. 05Tell the team working on it what the test is. They deserve to know the bar.

Most products that fail don't fail suddenly. They fade slowly while absorbing the company's best people. A clear test, set early, is kinder to everyone than a slow fade.

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.