Fix the bug before you build the feature. A 16-year argument against shiny.

We built a feature called Goals. Nobody used it for twelve years.

It was a pet project of mine, inspired by something Nike had done in their running app. We shipped it thin — missing the pieces that would've made it actually land — and it never took off. And then it just sat there. For a dozen years. An embarrassment in the product that our salespeople were literally coached not to show or talk about. Every one of those years it cost us something to maintain and returned nothing.

That's what low feature adoption looks like up close — not a number on a dashboard, but a feature you're quietly ashamed of and can't bring yourself to remove. And the lesson wasn't "we picked the wrong feature." It was that we had no discipline for deciding when a feature had failed and should be killed. We let it drift for a decade because killing things is hard and building new things is fun.

Nobody ever audits the bet

Here's the pattern that funds the graveyard. Features get built on a narrative: "this lands enterprise accounts," "this expands seats," "this closes the deals that need the security feature." Fine. But almost no one ever goes back and checks — how many seats did we actually expand? How many deals did the security feature actually close, more or fewer than we promised? The investment is real and unrecoverable: fifty to a hundred thousand dollars in development, plus years of maintenance, gone whether anyone adopts it or not. And because the narrative is never audited, you keep funding narratives that don't pay off.

The fix I'd insist on now is unglamorous: collect real demand data from customers and prospects before the investment, not after. It slows you down, and that's the point — a slower decision beats six figures down the drain on something that ends up in the graveyard.

The new-versus-polish trap

This is the deeper structural problem, and it runs through the entire product side of most SaaS companies. Faced with a choice between building something cool and new or improving an existing feature, the org almost always picks new — it feels like progress, it demos well, it's what gets people promoted. Meanwhile the support organization is hearing, every single day, that an existing feature could be great with a few fixes — and nobody's listening.

If you want to know where your product is actually broken, talk to your support team. They have the data and the customers' ears. Your ticket volume by feature is the most honest bug map in the company — the same five tickets every week are your roadmap, written by your customers. In a new SaaS company, I'd invest far more in polishing what already works and fixing its bugs than in chasing the next new thing. New rarely pays back what it promises.

Be willing to stop the roadmap

The lever most companies won't pull is the one that matters most. We tracked support-generated bugs at the leadership level, weekly — not buried in an engineering backlog nobody opened, but surfaced where decisions get made. And when that bug count climbed too high, outside our goals, we stopped product roadmap work and engineering projects to clear it. New features waited.

It feels wrong in a planning meeting — you're delaying features to fix bugs. But a pile of unresolved customer bugs is a louder problem than a late feature, even if it never feels that way in the room. Slow resolution on real bugs is a churn driver, and the only people who can reallocate the engineering capacity to fix it sit in leadership. Resolution time, ultimately, is a capacity-allocation decision — and the courage to make it is what keeps a product honest.

Kill, or commit — but decide

When a feature shows low adoption, run the real test: split it. These customers have it, these don't — does it drive any adoption, retention, or expansion? That's the true measure of success, and almost nobody runs it. Set a window — six months — and at the end, make a call: kill it or commit to it. Both are fine. Letting it drift into the graveyard for a decade is the only wrong answer. The cost of maintaining something nobody uses is real, and indecision is its own expense.