Gesia All articles
Product Strategy

Your Feature Request Is on the Roadmap. It's Been on the Roadmap for Three Years.

Gesia
Your Feature Request Is on the Roadmap. It's Been on the Roadmap for Three Years.

There's a slide in almost every enterprise software QBR that looks roughly the same. It's got a timeline, some color-coded swimlanes, and a handful of features your team has been asking about for the better part of two years. The account executive points to one of them and says something like, "That's definitely on our radar for H2." Everyone nods. Nobody writes it down. And six months later, H2 becomes Q1 of the following year, which quietly becomes "under active consideration."

Welcome to roadmap theater.

What a Public Roadmap Actually Is

Let's be honest about what a SaaS vendor's public roadmap is designed to do. At its best, it's a loose communication tool that gives customers a sense of direction. At its worst — and this happens more than vendors would like to admit — it's a retention mechanism. A way to keep you from churning to a competitor by dangling the promise of a feature you actually need.

The mechanics are simple. You submit a feature request. It gets upvoted by other customers. The vendor acknowledges it publicly, assigns it a status like "Planned" or "In Progress," and moves on. Meanwhile, their engineering team is heads-down on something else entirely — something that serves a different buyer profile, unlocks a higher price tier, or satisfies a compliance requirement for a vertical they're aggressively targeting.

Your feature? It's on the board. It just isn't on anyone's sprint.

The Segment You're Not In

Here's the part vendors really don't want to talk about. Most enterprise SaaS companies are simultaneously serving multiple market segments — often with very different needs and very different price points. The features that actually move through the development pipeline are the ones that serve the segment the vendor is trying to grow into, not the one they're already comfortable with.

If you're a mid-market customer on a standard plan, and the vendor is pushing hard into enterprise, your requested workflow improvement isn't the priority. The SSO configuration, the admin audit logs, the custom data residency options — those are the priority. Because those are the features that close seven-figure deals.

You're not getting the custom report builder. The Fortune 500 prospect in their pipeline is getting the custom report builder.

This isn't malicious, exactly. It's just the math of product investment. But the roadmap doesn't tell you that. The roadmap makes everything look equally possible.

The 'Coming Soon' Graveyard

Spend enough time in SaaS and you start to develop a dark sense of humor about certain phrases. "Coming soon." "On our roadmap." "We're exploring this." "Great feedback — we've shared this with the product team."

These are the phrases that live in the space between a vendor's actual priorities and what they're willing to tell you out loud.

The real tell is when a competitor ships the exact feature that's been sitting in your vendor's "Planned" column for eighteen months. Suddenly, the feature appears in your vendor's next release — not because your feedback finally landed, but because they couldn't afford the competitive pressure anymore. Your request wasn't the catalyst. The threat of losing deals was.

Some features genuinely do take time. Infrastructure work is hard. Compliance requirements create real constraints. But there's a meaningful difference between a feature that's delayed because it's technically complex and one that's perpetually deprioritized because it doesn't serve the vendor's growth thesis.

Customers rarely get told which situation they're in.

How Vendors Engineer the Illusion of Progress

One of the more sophisticated moves in roadmap theater is what you might call the partial ship. A vendor releases a version of a feature that technically checks the box without actually solving the problem. The status moves from "Planned" to "Shipped." The changelog entry looks reasonable. But when your team goes to use it, they find it only works under specific conditions, or it's missing the one piece that made it useful in the first place.

This isn't always intentional deception. Sometimes it's the result of an MVP that never got the follow-up iteration it needed. But the effect is the same: the feature is technically done, so it stops being a priority, even though it doesn't actually do what you asked for.

And because it's marked as shipped, it's harder to advocate for internally. The vendor can point to their changelog. Your IT lead sees that it's "available." The conversation stalls.

What You Can Actually Do About It

The first thing to accept is that vendor roadmaps are marketing materials. Read them the way you'd read a pitch deck — with interest, but with skepticism. The presence of your feature on a roadmap tells you almost nothing about when or whether it will arrive.

If a feature is genuinely critical to your operations, get it in writing. Not in a chat thread, not in a QBR recap email — in the contract. Vendors will push back on this, which is itself useful information. If they won't commit to a delivery window contractually, they probably don't have one.

It's also worth building a relationship with someone on the product side, not just your account team. Account managers are incentivized to keep you happy and retained. Product managers are incentivized to ship the right things. Those incentives don't always align, and talking to both gives you a clearer picture of where your requests actually stand.

Finally, pay attention to where a vendor is investing publicly — their conference announcements, their job postings, their recent acquisitions. That's where their real roadmap lives. If they're hiring heavily in enterprise security and you're asking for better small-team collaboration features, read the room.

The Smarter Way to Evaluate Vendor Momentum

Roadmaps are promises. Changelogs are receipts. If you want to understand where a vendor is actually going, stop reading their roadmap and start reading their release history. Look at the last twelve months of updates. What actually shipped? Who does it serve? Is there a pattern?

The vendors worth staying with are the ones whose shipped features tell a story that matches what they've been saying. The ones to watch carefully are the ones whose changelogs are full of polish updates and minor fixes while the big-ticket items stay perpetually parked in "coming soon."

Your feature might genuinely be coming. But if you've been waiting long enough to remember when you first asked for it, it's worth asking whether the roadmap is a plan — or just a very well-designed holding pattern.

All Articles

Related Articles

The Roadmap Is a Sales Deck in Disguise

The Roadmap Is a Sales Deck in Disguise

You Built the Software Around Your Business. That Was the Mistake.

You Built the Software Around Your Business. That Was the Mistake.

Signed, Sealed, Stranded: How SaaS Platforms Engineer Your Dependency

Signed, Sealed, Stranded: How SaaS Platforms Engineer Your Dependency