How to find product ideas worth building

Published 23 September 2026 · By Daily Product Idea · Our methodology

Why brainstormed idea lists rarely lead anywhere

Most lists of product ideas, including the ones an AI model will produce on request, start from a product: "an app that does X for Y". The idea arrives without a customer who asked for it, without evidence that the problem happens more than once, and without any sign of what people do about it today. You then spend weeks trying to work backwards to all three, and usually discover the problem was imagined, rare, or already solved well enough.

The alternative is to reverse the order. Find the problem first, in the words of the people who have it; check it is repeated; and only then design the smallest product that would remove it. This is the order Daily Product Idea works in, and the rest of this guide describes it step by step, using ideas we have researched and published as examples.

1. Look where the customer talks about their work

The best sources are places where people who would buy the product describe their own work: trade and professional forums, owner communities, a platform's public issue tracker, product reviews and support threads. Founder and startup communities are a weaker source unless founders are the customer, because people there tend to discuss other people's problems, or their own product.

• Deal Floor began with small-business owners describing thin margins eaten by stacked discounts, card fees and hours spent on prospects who never buy. Research then found the same problem in long-running contractor forum threads about whether to charge for estimates.
• Flight Deck began with developers on Hacker News asking how others juggle several AI coding sessions at once. The strongest evidence came later, from open issues on the Claude Code repository itself: the platform's own users asking to be told which session is waiting for them.

2. Listen for pain, not for requests

"Someone should build X" is weak evidence: it is a guess about a solution. What you want are the signs that a problem is real and costly:

• A workaround: the spreadsheet, the habit, the manual check people use instead of a tool.
• A consequence: money lost, time wasted, a risk taken, a customer let down.
• Repetition: the same task, done by hand, every week.
• Spending: people already paying for a partial answer, such as a guide, a consultant or a clumsy tool.

In Deal Floor's case the workarounds were specific: a non-refundable deposit invented on the spot to screen out tire-kickers, or a manual margin check on each deal that gets skipped when the owner is busy. A workaround like that tells you the problem is felt, and shows the smallest thing a product would have to beat.

3. Group what you find into one clearly stated problem

Individual posts are signals, not problems. Put together the ones that describe the same underlying problem for the same kind of customer, and write that problem down in one sentence. Before we research a problem we expect, as a guideline:

• at least three credible signals, from at least two different places;
• at least one published in the last 90 days;
• an identifiable customer; and
• a describable consequence or workaround.

Grouping is where most of the judgement lies. A group that is too broad produces a vague product. Trade Reality Dossiers came from a group of posts by people entering unfamiliar trades: a would-be business buyer asking how broker agreements work, someone opening a spare-parts shop with no experience, a juice maker unable to find a safe preservation method. The shared problem, "I cannot find trustworthy, practical guidance on how this trade works before I commit money", is real. But the posts span so many trades that any product has to choose one trade to start with, and that choice is itself a hypothesis.

4. Treat popularity as context, not evidence

A post with thousands of upvotes in one large community feels like strong evidence. It is weaker than the same problem raised repeatedly, in plain language, across several smaller communities by people who do not know each other. Upvotes tell you a post was agreeable; independent repetition tells you a problem is common.

5. Only now, propose the smallest product

With a clearly stated problem, propose the smallest product that would remove it for one kind of customer, and write down the single assumption it depends on most. For Flight Deck, the proposal was a terminal status board with one isolated workspace per agent; the riskiest assumption was that developers would keep several agents productive once they could see which one needed them.

6. Research it before you commit

Then test the problem against sources outside the community it came from: reviews and support complaints, job and freelance postings, search demand, issue trackers, and above all direct conversations with the customer. Record what counts against the idea as carefully as what supports it. Flight Deck's research found strong evidence of the problem, and also that several free tools and a built-in platform feature already covered much of the proposed product. Both findings are on its page, and both shaped its score.

A short checklist

1. Pick an audience you can reach, and find where they discuss their work.
2. Collect posts that show a workaround, a consequence, repetition or spending.
3. Group them into one problem, stated in one sentence, for one kind of customer.
4. Check the group has at least three signals from at least two places, one of them recent.
5. Propose the smallest product, and name the assumption it depends on most.
6. Look for evidence outside the original community, including evidence against.
7. Test the riskiest assumption before building anything else.

Every idea Daily Product Idea publishes has been through these steps, and its page shows the sources it was built from. See how ideas are researched and assessed for the full method, or browse the researched ideas.