TL;DR: Use a startup idea database to create a shortlist of problems to investigate. For each candidate, separate the proposed product from the evidence behind it, check the original context and decide what you need to learn next. The useful output is a research direction you can test.
A catalog can make the beginning of this work easier. It can also make it tempting to keep collecting attractive ideas without learning anything about a customer. A shortlist becomes useful when each entry has a specific job, supporting observations and an unanswered buying question.
What kind of entry are you looking at?
The name “startup idea database” can cover several kinds of material. Read an entry with its origin in mind:
| Material | What it gives you | What still needs checking |
|---|---|---|
| A product proposal | A possible solution and customer | Whether that customer has the problem |
| A complaint summary | An interpretation of a reported problem | Whether the summary matches the source and your intended segment |
| A feature request | A desired change to an existing product | How important it is and whether it supports a separate purchase |
| A business example | A model someone has attempted | Whether its conditions apply to you today |
| A scored opportunity | A way to prioritize reading | What the score measures and what it leaves unresolved |
An AI-generated proposal can be a useful prompt for research. A public discussion can contain a useful observation. They play different roles in your notes: one suggests what you might build; the other helps you investigate why anyone would need it.
PainHunt's research records include extracted problems alongside suggested product directions. Read the problem and its source before accepting the proposed solution. How PainHunt works explains that process; the pain point database guide explains how to assess the underlying evidence.
Start with a job you can investigate
Choose a role and a recurring task. “Software for agencies” leaves almost every important question open. “An account manager preparing a client report from several systems” gives you a workflow to observe.
That is an illustrative scope, not a finding about the size of the agency market. Its value is that it tells you what to search for and whom to talk to.
Try the task, the current workaround and the failure separately. For example, investigate reporting, manual exports and reconciliation as separate searches. Keep the customer definition visible so an interesting result from a different segment does not quietly change your research question.
Build a shortlist with evidence attached
For each candidate, keep a compact note:
- The customer and the job they are trying to complete.
- A source link and the date of the observation.
- The current workaround or existing product.
- The consequence of the problem.
- The person who could approve a purchase.
- The strongest reason the idea might fail.
A record describing several frustrations can inspire several product ideas. It still originates from that record. Likewise, a discussion repeated across sites does not automatically become several independent accounts of the problem.
Open the source when it matters to the decision. Check whether it describes a recent incident, an opinion about a category, a request for help or a promotional post. A confident summary can conceal those differences.
Compare candidates on the same questions
Comparing an idea you know well with one you have only read a polished description of creates an uneven contest. Give each candidate the same questions before deciding which looks strongest.
| Question | What a useful answer contains |
|---|---|
| Who has the problem? | A role and a bounded customer segment |
| When does it happen? | A trigger, recurrence or deadline |
| What do they do today? | Existing software, manual work or a service |
| What does failure cost? | A supported description of time, money, delay or risk |
| Who can buy? | An identified budget owner and buying process |
| What blocks adoption? | Access, migration, integration or approval constraints |
| What would disprove the idea? | A finding that would change your next step |
Leave missing answers visible. An unknown budget owner should remain an unknown, rather than becoming a positive score because the problem sounds urgent.
The B2B buyer and workflow checklist develops the buying side of this comparison. It is particularly useful when the person describing the pain is different from the person approving software spending.
Read dates and coverage carefully
There are several dates worth distinguishing: when someone reported a problem, when a research system collected it and when an article about it was updated. A recently added record may describe an older discussion. Check whether the relevant product or workflow has changed since then.
Coverage matters too. Public software discussions can help with some customer segments while offering little visibility into others. An empty or sparse search in a narrow industry is a reason to investigate coverage and terminology before concluding that demand is absent.
For a country-specific idea, check the customer location, language, existing tools and local buying conditions explicitly. The regional demand guide covers that distinction.
Choose the next test, then stop browsing
A useful research session ends with an action that resolves an uncertainty:
- If the workflow is unclear, observe a recent example with someone who does the work.
- If the buyer is unclear, investigate how a comparable purchase was approved.
- If alternatives look satisfactory, check whether your intended customer has an unresolved constraint.
- If adoption looks difficult, test whether the customer can supply the access or inputs your product needs.
- If the buying case looks credible, propose a bounded pilot with an observable outcome.
Record the decision and why you made it. The validation report template gives you a place to keep the evidence, counterexamples and next test together.
You can start with Idea Validator and inspect related research in the Pain Point Browser. Keep the shortlist small enough that you can investigate the people and workflows behind it. That is how a collection of ideas becomes a basis for a decision.