The problem
The scary part of a new idea is not that someone else may have already built it. The scary part is not knowing how close they got.
A lot of ideas feel novel when they are still in your head. You know the version you mean. You know the pain point, the angle, the specific audience, the weird constraint that makes it interesting. But the world does not compare your idea against the version in your head. It compares it against everything already tried: papers, products, GitHub repos, old forum threads, dead startups, blog posts, patents, half-finished demos.
So before building, I want a better habit: run a prior-work review.
Not to kill the idea. Not to get an oracle verdict on whether it is “novel.” I want to see what’s already out there clearly enough to decide whether my idea is a real new angle, a small variation, or just something I had not personally encountered yet.
Novel does not mean never done before
“Has anyone ever done this?” is usually the wrong question.
Almost every useful idea is a remix. A new interface on an old workflow. A better target user. A narrower problem. A different distribution channel. A known technique applied somewhere people do not normally apply it.
The better question: what already exists, and how is my version actually different?
That difference might be technical. It might be product-shaped. It might be about workflow, timing, audience, cost, or taste. Either way, it has to hold up once you line it up against existing work.
A good prior-work review should not end with a confident verdict like “novel” or “not novel.” That flattens too much. What I want is the raw comparison: here are the closest things, here is what they do, here is where they overlap, and here is where they differ.
Then I can decide.
The workflow
The workflow is simple.
First, describe the idea in plain language. A paragraph is enough if it includes the problem, the rough approach, and who it is for. If the idea is too vague, clarify it before searching. “AI for product teams” is not searchable. “A Slack bot that detects duplicate feature requests across customer channels” is.
Then search broadly. Papers, products, repos, patents, blog posts, forums, anything that might count as prior work. Do not stop at one reassuring result. Keep going until the same themes start repeating.
Then structure the findings by closeness. The most similar thing goes first, not the most famous thing. For each item, write down what it is, what it does, how it overlaps with the idea, and how it differs.
I named my version of this workflow /research. The command is not the important part. The shape of the output is.
Example
Say the idea is:
A Slack bot that flags duplicate feature requests before the product team creates another ticket.
A useful research report would not just say “there are feature request tools.” It would compare the closest prior work.
1. Productboard
Productboard is a product management platform. It centralizes customer feedback, links it to feature ideas, and helps product teams prioritize roadmap work.
Teams collect feedback from multiple sources, group related requests, score demand, and connect customer evidence to product decisions. It already handles feedback deduplication in a broad sense. Multiple customers can be linked to the same feature idea, which helps prevent every request from becoming a new roadmap item.
But it is a full product management system, not a lightweight Slack-native bot. The workflow expects teams to use Productboard as a source of truth. The proposed idea focuses on catching duplicates at the moment someone is about to create or discuss a request in Slack.
2. Canny
Canny is a customer feedback product. Teams get a portal where users can submit, vote on, and discuss feature requests.
It collects requests, merges duplicates, tracks status, and gives product teams a public or private feedback board. Duplicate handling is built in: teams merge similar posts and consolidate demand.
The catch is where that happens. Canny deduplicates inside its own feedback board. The proposed idea lives in Slack and tries to detect duplication before a request becomes another artifact to manage.
3. Linear / Jira duplicate issue detection
Issue trackers often support duplicate detection through search, linking, related issues, or automation. Teams mark issues as duplicates, link related work, and use search or automation to reduce repeated tickets.
Same underlying job: prevent teams from tracking the same request in multiple places.
These systems usually catch duplication after an issue already exists. The Slack bot idea is more conversational and pre-ticket. It catches “we already heard this” while the team is still talking.
What this gives you
This kind of output does not answer the question for you. That is the point.
After reading it, I might decide the Slack bot is not interesting because Productboard and Canny already cover the real need. Or I might decide the opposite: the interesting part is that existing tools require a heavyweight feedback system, while my version catches duplicates inside the messy conversation layer where product teams already live.
That is a much better conclusion than “I think this is novel” or “someone already built something kind of similar.”
Research is not permission. It is contrast. Once I can see what already exists, I can see whether my idea has a sharper edge.