Researching Latent Demand

When the question is what to build, reason from a validated problem, not from a solution you imagined. This developer asks for this explicitly ("do pain research instead of guessing", "reason from the problem instead of solution").

The method

1. Research real pain first. Before proposing features, look at where the pain actually shows up: HN, Reddit, GitHub issues, pricing complaints, reviews, competitor gaps. Ground each idea in evidence of a real problem.
2. Reason from the problem, not the solution. State the underlying need, then let the feature follow. Do not start from a feature and back-fill a justification.
3. Apply the painkiller-not-vitamin test. Default skeptical. Favor things that relieve an acute, recurring pain (painkillers) over nice-to-haves (vitamins). "research... latent demand features needed (no vitamins)."
4. Map the competitive gap. Compare against what competitors do and do not do; the gap is often where the latent demand sits.
5. File the results as tracked issues. Turn the prioritized findings into GitHub issues (or the project's tracker) before building, so the plan is durable and a subagent can pick it up. Do not leave it as a chat list.

When to apply

Feature ideation, "what should I build", roadmap or prioritization requests, and competitive gap analysis. Reach for real research (web/GitHub) rather than answering from generic product intuition.