TL;DR: Use GitHub issues to discover a specific workflow that breaks or requires a workaround. Read what happened next, distinguish separate reports from a single discussion and investigate the buyer outside the issue tracker. The useful result is a testable customer problem, not a ranking of repositories by complaints.
Issue trackers expose details that a broad market description can miss: a version constraint, an integration boundary, a manual export or the reason a team cannot adopt an existing feature. Those details can help narrow an idea. They can also describe a project-specific bug that will disappear with the next release.
What does an issue count actually count?
In a check of records first added to PainHunt's research corpus from 29 September through 28 October 2026, we found 647 GitHub issue-linked records with extracted pain points. That is a count of stored research records. It is not a count of independent buyers, unresolved problems or subscriptions. A record's addition date is also different from the original issue's publication date.
The same distinction applies to your own research. An issue can contain several problems; one problem can appear in several linked issues. A comment, reaction and duplicate report are different observations, and they should remain distinguishable in your notes.
How PainHunt works explains the extraction process. Use the summary to locate material, then return to the discussion before making a decision that depends on its details.
Start with a workflow, then choose repositories
Choose a task and a user before searching. For example, an illustrative research scope could be “a developer exporting records from a local tool into a reporting workflow.” That gives you terms for the task, the workaround and the failure: export, CSV, manual, reconciliation or missing fields.
Pick repositories used in that workflow, including relevant integrations. Search both open and closed discussions. GitHub's issue search documentation supports repository and organization scopes, issue-only filters and open or closed state filters.
Replace the placeholders in these examples with a repository or organization you intend to research:
repo:OWNER/REPOSITORY is:issue "workaround"
repo:OWNER/REPOSITORY is:issue is:closed "export"
org:ORGANIZATION is:issue "manual"
Search several descriptions of the same task. The absence of a particular phrase can reflect terminology or coverage, rather than the absence of the problem.
What kind of record have you found?
Classify the material before turning it into an opportunity:
| Record | Useful question | Premature conclusion to avoid |
|---|---|---|
| Bug report | Which version and workflow fail? | Everyone needs a new product |
| Feature request | What is the person trying to accomplish? | The requested feature supports a standalone business |
| Integration limitation | Which systems and permissions create the boundary? | A connector alone will remove every adoption barrier |
| Workaround | What work does it require and when? | The workaround is costly for every user |
| Implementation task or pull request | Is this planned work, a proposed change or a reported need? | Every tracker item is a customer complaint |
| Product announcement or promotion | Does it contain an independent report of use? | A product pitch establishes buyer demand |
If you collect data through the API, GitHub's Issues endpoint documentation notes that responses can include pull requests, identified by the pull_request field. Filter them explicitly if your unit is issue reports. Keep automated maintenance activity separate when investigating human workflow problems.
Read the resolution before calling a gap open
Read beyond the first description. Check linked issues, the maintainer's explanation, the relevant release and the author's follow-up.
An open issue may have a workable answer in the comments. A closed issue may be a duplicate, a deliberate scope decision or a request the maintainer does not intend to implement. The status alone does not establish whether the underlying job is solved for your intended customer.
Keep a small evidence note: source link, observation date, affected workflow, current workaround, resolution and the condition under which the problem remains. If that final condition is unclear, leave it as a question.
When do repeated reports support a broader problem?
Group by job and consequence rather than by keyword. Two reports about “export” may concern entirely different users and data. Several comments in one thread may describe the same incident or repeat the original request.
Look for separate contexts that share a meaningful constraint. Are different teams doing similar manual work? Does the workaround fail for the same reason? Are they using current versions? Can the existing project reasonably address it?
Treat this as a way to prioritize interviews, not as a market-size calculation. Public issue trackers represent the people and projects that use them and choose to report there. They do not give you a representative sample of all potential customers.
Who could buy a separate solution?
A person can want a feature while preferring it to remain part of the existing project. Investigate what a separate purchase would change: installation, permissions, data movement, maintenance, vendor approval and responsibility when something fails.
Ask about a recent example and the current alternative. If the issue includes an offered budget, establish what that budget covers. Payment for a one-off implementation does not automatically establish willingness to buy a recurring SaaS subscription.
For a team workflow, use the B2B buyer checklist to distinguish the user, approver and budget owner. Compare the direction against existing products with the idea competition guide.
Turn the research into a small next test
Write one bounded hypothesis: a defined customer needs to complete a particular job, the current workaround has a specific limitation and a proposed offer could improve that outcome.
The next test might be observing the task, trying a manual service, demonstrating an integration against permitted test data or offering a small paid pilot. Name what would make you reject the idea, including a recent release that already solves it.
Use the Pain Point Browser and Idea Validator to look for context across sources, then keep the decision in a validation evidence brief. The value of the tracker research is the sharper question it gives you to test.