Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Cost-to-Serve Data to Kill Unprofitable Features
Transcript
- Lucas: So there's a concept in logistics and retail called cost to serve — the total cost of delivering a product to a specific customer. But what happens when you apply that same lens to software features? One CTO I've been following did exactly that, and what she found was pretty striking. Luna: I've heard of cost to serve in supply chain, but for features? How do you even calculate that? Lucas: Right, so the company in question is a mid-market SaaS platform — think project management software with integrations, reporting, the usual. About 200 employees, maybe 50 engineers. The CTO, let's call her Sarah, had a hunch that a lot of their engineering time was going into features that barely anyone used. Luna: And that's a classic problem. Most product teams have a graveyard of features nobody touches. Lucas: Exactly. But Sarah wanted to quantify it. So she built a model that tracked three things for every feature: development hours spent on new enhancements, maintenance hours from bug fixes and support tickets, and infrastructure costs like server compute and database queries. She then mapped that against feature usage data from their product analytics. Luna: So it's like a profit and loss statement for each feature. Lucas: Yeah, exactly. And what she found was that 12 percent of their features — about 18 features out of 150 — consumed 40 percent of total engineering maintenance time, but generated zero incremental revenue. They were either free-tier features or legacy features grandfathered in from an old pricing model. Luna: Ouch. So essentially, those features were a tax on the engineering team. Lucas: Precisely. And the kicker is that no one had ever bothered to look. The features were just there, absorbing resources year after year. Sarah calculated that if they could sunset those 18 features, they could free up about four engineering months per year — that's about 20 percent of a 20-person team's capacity. Luna: That's a huge chunk. But I imagine the business side wasn't thrilled about removing features. How did she make the case? Lucas: She didn't go in saying 'let's delete stuff.' She presented the data in a cost to serve dashboard, showing each feature's net contribution. She also added a risk column: what percentage of active users would be affected if the feature disappeared. For most of those 18, it was less than 2 percent of users — and those users were on the free tier. Luna: So she framed it as a trade-off: keep supporting features for 2 percent of free users, or reinvest that engineering time into features that paying customers actually want. Lucas: Exactly. The CEO was on board once they saw the opportunity cost. They agreed to a phased sunset: first, they stopped all new enhancements on those features. Then they added deprecation notices in the UI. After three months, they archived them completely. The key was that they also built a migration path for any free users who wanted to move to a supported feature — but almost no one did. Luna: And what happened to engineering velocity after that? Lucas: Within six months, the team's lead time for new features dropped by about 15 percent. Bug fix time went down even more because there were fewer legacy code paths to debug. Sarah told me the biggest surprise was that developer satisfaction went up — engineers hated maintaining those zombie features. Luna: I bet. There's nothing worse than fixing bugs in a feature you know nobody uses. Lucas: Right. And the cost to serve model became a regular part of their quarterly planning. Now, before the product team greenlights a new feature, they also estimate its expected maintenance burden. It's changed how they think about feature complexity. Luna: So it's not just about cleaning up the past — it's about making better decisions going forward. Lucas: Exactly. And I think this is a framework any engineering leader can adapt. You don't need a fancy tool — you just need usage data, a time-tracking system, and a spreadsheet. The hard part is getting the business to accept that features have ongoing costs. Luna: And that some features are actually liabilities, not assets. Lucas: Yeah. Sarah framed it as technical debt, but at the feature level. It's a really concrete way to make the abstract concept of tech debt visible to non-technical stakeholders. Luna: Honestly, this whole conversation has been really actionable. If today's episode gave you something you can use, you know where to find us. The link is buy me a coffee dot com slash fexingo. It's a small way to keep the show ad-free and focused on stuff like this. Lucas: Yeah, we really appreciate it. And we'll keep bringing more of these real-world playbooks. So back to the cost to serve model — one thing Sarah emphasized was that the model itself evolves. In the first pass, they only tracked engineering hours and infrastructure. Later, they added customer support costs. Luna: Support costs? How did that change the picture? Lucas: It turned out that a few features generated disproportionate support tickets — often because the UI was confusing. Those features had high maintenance costs that weren't obvious from just engineering time. When they factored in support, the list of candidates for sunsetting grew. Luna: So it's like peeling an onion — each layer reveals more hidden costs. Lucas: Exactly. And that is the real power of cost to serve: it forces you to account for the full lifecycle cost of a feature, not just the initial build. Most teams celebrate shipping a feature, but they never look at the bill that comes due every month after. Luna: So for any CTO listening, what's the first step? Where do you start? Lucas: Sarah's advice was simple: pick your top ten features by usage and your bottom ten by usage. Then ask your engineering team to estimate how much time they spend on each per month. You'll probably find a few surprises. Then take that to your product counterpart and start the conversation. Luna: And the business side might push back, but at least you'll have data. Lucas: Right. Data is the only language that works across departments. And once you've done it once, it gets easier. The team at Sarah's company now runs the cost to serve analysis every quarter as part of their planning cycle. Luna: It's a discipline, not a one-time cleanup. Lucas: Exactly. And I think that's the takeaway here: engineering leaders need to treat features like products with their own P&L. Not everything that costs money is worth keeping. Sometimes the most impactful thing you can do is stop doing something.