Their roadmap board has a rejection pile

I spent twenty minutes last week scrolling a competitor's public feature-request board. Not the "Planned" column — everyone reads that one. The filter I kept coming back to was Closed: won't do.

Forty-odd requests in there. Some with a hundred upvotes. Each one with a one-line note from a PM explaining, politely, why it isn't happening.

That's a strategy document. It just isn't labeled as one.

What a decline actually commits them to

A roadmap tells you what a team hopes to do. A rejection tells you what they've decided to stop arguing about internally.

The distinction matters because roadmaps slip constantly and cost nothing to publish. "Planned" is cheap. But writing "we're not building this" under a request with real upvotes is expensive — it disappoints paying customers, and it's hard to walk back six months later without looking directionless. Teams don't do it casually.

So when I see a competitor decline on-prem deployment, or a native mobile app, or granular role permissions, I read it as a boundary they intend to hold for at least a year. That's a boundary you can build against, and one you can say out loud in a sales conversation without it going stale by next quarter.

The reasons are worth reading closely too. "Not on our roadmap" is a shrug. "This conflicts with how our data model works" is an architectural confession. The second one tells you the feature is expensive for them in a way it might not be for you.

The label change is the event

Here's the part that's easy to miss if you only check the board once: items move.

A request sits in "Under review" for eight months, then flips to "Planned." Another goes from "Planned" straight to "Won't do" — that one is the interesting one, because something changed their mind. A quarter later you see a flip in the other direction, usually right after a competitor of theirs shipped it.

Reading the board today gives you a snapshot. Reading the transitions gives you the argument they're having internally. But nobody has the discipline to re-check a feature portal weekly by hand, which is exactly the gap Seeto fills — it watches public surfaces continuously and reports each change as a discrete event, so a status flipping from "Under review" to "Won't do" lands as something you can date and file rather than something you happen to notice. It won't tell you why they changed their mind. It will tell you when, which is usually enough to go find out.

Two practical notes. Not every company runs a public portal — check feedback., roadmap., or a Canny or Productboard link in their help center footer. And upvote counts are noisy and easy to brigade; the status label is the signal, not the number. A declined item that quietly disappears counts too — file it like any other change you decided to ignore.

Their changelog tells you what shipped. Their community tells you what hurts. The rejection pile tells you what they've given up on — and that's the one your positioning can actually stand on.