A few years back, I was consulting for a mid-sized SaaS company that had a graveyard of features in its codebase. Real, finished code. One was a collaboration tool that had taken three engineers six weeks to build. It had never seen production. When I asked the VP of Product about it, she shrugged and said, ‘We built it to show the board we were serious about enterprise.’ The feature wasn’t built for users. It was built for a meeting.
That conversation reframed how I look at product roadmaps. The conventional story is that features get killed because priorities shift, resources dry up, or user research changes the direction. Sometimes that’s true. But there’s a more uncomfortable explanation that nobody in the industry talks about openly: a significant portion of unshipped features were never intended to ship. They were built to serve internal purposes that have nothing to do with the product.
This isn’t incompetence. It’s a rational, if dysfunctional, response to the incentive structures inside tech companies.
Features Are Negotiating Currency
Product teams inside large companies operate in a constant negotiation with stakeholders: executives, investors, enterprise sales, and partner organizations. Features are one of the few tangible things a product team can produce quickly, and tangible things have negotiating power.
A feature that exists in staging, even one never destined for users, can close a partnership conversation, satisfy a board member’s anxiety about competitive positioning, or give an enterprise sales rep something concrete to promise a prospect. The implicit agreement is that the feature might ship someday, which keeps everyone happy without committing to a timeline.
This is why enterprise software is particularly prone to feature graveyards. The sales cycle is long, the buyers are sophisticated, and a roadmap screenshot in a pitch deck carries real weight. Building a feature to support a sales process, rather than to serve users, is a calculated trade-off that many product leaders make without ever saying it out loud.
Unshipped Features Are a Form of Organizational Insurance
Product teams also build features they know might never launch because shipping decisions are often made by people who didn’t build anything. A feature sitting in the codebase is optionality. It can be resurrected if the competitive landscape shifts, if a new executive arrives with different priorities, or if a customer segment that was previously ignored suddenly matters.
Google has done this repeatedly and visibly. Features get built, shelved, and then quietly relaunched years later under different branding. What looks like waste from the outside is often a deliberate preservation of future options. The cost of keeping working code on a branch is low. The cost of rebuilding from scratch when you need it urgently is very high.
The problem is that this logic, sound at the individual feature level, creates teams that have lost the habit of shipping. When building something becomes decoupled from launching it, you lose the feedback loop that makes products better.
Roadmaps Signal Intent to Employees, Not Just Customers
Here’s the one that really doesn’t get discussed: features get built to retain engineers.
Talented engineers leave when the work gets boring. A roadmap full of ambitious, technically interesting features keeps them engaged, even if leadership already knows that half of those features will never reach users. The feature becomes a retention tool, a way to tell a senior engineer that yes, you’ll get to work on that distributed caching layer you’ve been excited about.
This isn’t entirely cynical. Keeping good engineers happy has genuine business value. But it creates a culture where the act of building is treated as the end goal, rather than a means to actually putting something useful in front of users. The incentive to delete code and simplify systems never takes root because there’s organizational reward for complexity.
The Counterargument
The reasonable pushback here is that exploration has value, and you can’t always know in advance which features will matter. Prototyping, even at production quality, is a legitimate way to stress-test ideas. Some of the most important features in tech history were built speculatively and launched only after the right moment arrived.
This is true. The problem isn’t that unshipped features exist. It’s that most companies have no honest accounting of why a feature was built in the first place. When you mix genuine exploratory work with features built for board presentations and engineer retention, you get a codebase and a culture that can’t distinguish between the two. Decisions about what to ship get muddier because the original intent was never recorded, and now every dead feature has a champion who insists it was always a serious product bet.
The fix isn’t to stop building speculatively. It’s to be honest, internally, about what you’re doing and why.
What This Means for Anyone Reading a Roadmap
If you’re an investor, a customer, or someone evaluating a company’s product velocity, understand that a roadmap is as much a political document as a product one. Features announced with confidence are often there to manage a relationship, not to solve a user problem. The question to ask isn’t ‘what are they building’ but ‘who is this feature actually for.’
If you’re inside one of these companies, the discipline worth fighting for is a two-sentence brief written before any feature gets built: what user problem does this solve, and what happens if it doesn’t ship. If you can’t answer both questions, you’re probably not building a product feature. You’re building something else, and you should at least know that going in.
