Every SaaS company has a page most people never visit. It's usually linked from the footer, or hidden behind a "share your idea" button inside the app. It has an ugly functional interface and a lot of small type. Your competitor doesn't think of it as marketing. They think of it as a support release valve.
It's the most honest page on their entire site.
Landing pages sell what's built. Changelogs report what shipped. The public feature request board — Canny, Frill, ProductBoard, Nolt, GitHub issues, whatever they use — records what didn't happen and who wanted it to. It's a confession posted in public, and almost nobody reads it as one.
What the board actually is
A public feature request board is three things stacked on top of each other. It's a support triage tool ("we hear you, go upvote it"). It's a signal for the roadmap team. And it's a public admission of every pain point that made it past the support layer without being resolved.
The third one is the interesting one.
When you look at a competitor's board, you're looking at things that: enough customers wanted to file a request about, that a support agent judged legitimate enough to log publicly, that the company hasn't fixed, and that other customers found and upvoted because they wanted the same thing. Every step is a filter. What's left is real.
The three signals
Not every request on the board tells you the same thing. There are three worth learning to distinguish.
The high-vote fresh request. A feature filed in the last month with fast-growing vote counts. This is a live pain point actively driving customer frustration right now. If it's in your category, it's telling you what customers are shopping for a solution to today. If you already have that workflow — or you can ship it — the marketing writes itself.
The high-vote stale request. A feature with hundreds of votes that's been sitting open for eighteen months. This is the confession. The company has decided, explicitly or by omission, that they're not building it. The reasons are almost never public but they're always structural: it doesn't fit the architecture, it doesn't fit the pricing, it would cannibalize a higher tier, it would break onboarding for the majority. Whatever the reason, they've committed to leaving that gap open. Someone else can walk into it.
The explicitly declined request. Some boards let admins mark a request "won't build" or "out of scope." This is the strongest signal on the internet, because it's the competitor saying out loud what they're not going to do. It's a public commitment against a category of customer. That customer is now unattached and looking — and probably reading the comment thread on the "won't build" ticket to figure out what to do instead.
The first tells you what to build. The second tells you where a gap will stay open. The third tells you where an entire cohort of buyers is stranded.
The comments are the customer voice
The votes are the vote. The comments are the interview.
When customers comment on a feature request, they explain why they want it. They describe the workflow they're currently doing without it. They mention what they'd pay for it. They say what they'll do if it doesn't ship. That language — unprompted, uncontaminated by any product marketing, written to persuade an audience of one product team — is closer to raw customer voice than almost any other source you can mine.
It's cleaner than Reddit because it's on-topic by construction. It's cleaner than review sites because the person isn't grinding an axe. It's cleaner than support tickets because it's public and considered. The customer knows they might be quoted, and they still wrote it. That's a level of intent you rarely see anywhere else.
Two things to look for specifically. The workaround language: "right now I have to export to CSV and then paste it into…" is a duct-tape signal delivered directly, no interpretation needed. And the switching language: "we're evaluating X and Y and this feature is the deciding factor" is a switching thread happening in slow motion, in public, on the losing company's own website.
Reading between platforms
Not every competitor runs a public board, and the ones that do use different tools. That matters.
Canny, Frill, and Nolt are usually the most surface-readable — requests are structured, votes are visible, comments are open. ProductBoard often runs a lightweight public view that hides most of the interesting internal state. GitHub Issues, for open-source competitors, is denser but noisier — you have to separate real feature requests from bug reports and drive-by complaints, and read for reactions instead of vote counts.
The absence of a public board is itself a signal. A company that used to run one and shut it down usually did so because the "won't build" pile got too embarrassing. A company that has never run one is either small enough that support and roadmap live in the founder's head, or big enough that "public roadmap" has been declared a legal risk. Both tell you something about how they operate.
The workflow that fits
Concretely: subscribe to your top three competitors' boards if the platform allows it, and add the URLs to a weekly review otherwise. What you're looking for isn't the whole board. It's the delta. New high-vote requests, requests that jumped in vote count this week, requests that got a planned or won't build status change.
Then read the comment thread on anything that moved. Not to decide whether to build the feature. To see how the customer describes wanting it. That description is the copy for your landing page, your reply on the Reddit thread where somebody's asking about the same problem, the outreach message that doesn't sound like every other outreach message. It's the language they already speak, sitting on your competitor's website, waiting for you to write it down.
A lot of what you find won't be actionable. Requests that don't fit your product, requests too small to matter, requests that duplicate what you already ship. That's fine. The point isn't to build everything the board asks for. The point is to know, faster than your competitors, which of your own customers' pain points are being actively felt right now, and which of your competitor's customers are quietly getting ready to leave.
The uncomfortable part
If you're running the same tool for your own customers — and you probably should be — the same read is available on you. Every request you left open is a confession too.
That's the trade. A public board is a support release valve and a customer voice channel and an implicit roadmap statement all at once. It leaks in every direction. The companies that run them well aren't trying to hide the leak. They're making sure the story it tells is one they'd be willing to write themselves.