The P&L of a Feature: Stop Building "Squatter" Software

There is a fundamental accounting error in how most Engineering teams operate.

We treat Code as an Asset.

We celebrate "Lines of Code Written" or "Features Shipped." We think that a product with 100 features is twice as valuable as a product with 50.

This is false.

In financial terms, Code is a Liability.

Every line of code you write is a commitment to maintain, debug, secure, and upgrade that code forever. It is debt.

The only "Asset" is the Outcome that the code produces (Revenue, Retention, or Efficiency).

If a feature exists in your codebase but does not generate an Outcome that exceeds its Maintenance Cost, it is a Squatter. It is living in your house without paying rent.

Here is how to calculate the P&L (Profit and Loss) of a feature and evict the squatters.

1. The Cost Side: The "Maintenance Mortgage"

Most Product Managers calculate cost as:

• "It will take 2 engineers n weeks to build. That’s $10,000."

This is the Down Payment. It ignores the Mortgage.

The real cost of a feature includes:

1. Infrastructure: The S3 storage, the database IOPS (see our FinOps article).
2. Cognitive Load: Every new feature adds complexity. It makes the next feature harder to build.
3. Support Tickets: Even a "perfect" feature generates questions ("How do I use this?").
4. Migration Tax: When you upgrade from React 18 to 19 next year, you have to upgrade this feature too.

The Rule of Thumb:

The annual maintenance cost of software is roughly 20% to 50% of its original build cost.

If you build a $100k feature, you just signed up to pay $30k/year forever.

2. The Value Side: Revenue vs. Proxies

Calculating value is harder. Not every button has a "Buy" function.

We categorize value into three buckets:

• Type A: Direct Revenue (The Cash Cow)
  • Example: A "One-Click Checkout" button.
  • Metric: Conversion Rate lift.
  • Calculation: (Extra Orders * Avg Order Value) - Maintenance Cost.
• Type B: Retention (The Moat)
  • Example: A "Dark Mode" or a "Dashboard."
  • Metric: Churn Reduction.
  • Calculation: Does the cohort of users who use this feature stay longer than those who don't? (LTV Lift).
• Type C: Efficiency (The Force Multiplier)
  • Example: An internal Admin Panel.
  • Metric: Hours Saved.
  • Calculation: (Support Agent Hourly Rate * Hours Saved) - Maintenance Cost.

If you cannot map a feature to one of these three buckets, why are you building it?

"Because the CEO wants it" is not a P&L line item.

3. The Audit: Evicting the Squatters

Once a year, you must conduct a Feature Audit.

Print out a list of every major feature in your product and ask:

1. Usage: What % of users touched this in the last 30 days?
2. Impact: If we deleted this tomorrow, would churn increase?

The "Zombie" Problem:

You will find features used by 0.5% of users.

Engineers will say: "Let's just leave it. It works."

NO.

That "dead" feature is blocking your database migration. It is confusing new users. It is a security vulnerability waiting to happen.

Delete it.

The bravest thing a Product Leader can do is not to launch a new feature, but to sunset an old one.

Deleting code is an strong way to pay down the principal on your Technical Debt.

4. The Culture of ROI

How do you shift a team from "Feature Factory" to "P&L Owners"?

You change the Definition of Done.

• Old Definition of Done: "Code is merged, tested, and deployed."
• New Definition of Done: "Code is deployed, and we have measured the impact."

If a team ships a feature and cannot tell you the ROI three months later, they didn't finish the job.

They just spent the company's money without getting a receipt.

Summary

Stop viewing your product roadmap as a "Wish List." View it as an Investment Portfolio.

• Some bets will fail (Negative ROI). That’s fine. Cut your losses quickly.
• Some bets will win (Positive ROI). Double down on them.
• But never, ever let a feature sit in your codebase "just because."

Code that doesn't pay rent must be evicted.