| name | researching-latent-demand |
| description | Decide what to build from real pain and market research, not guesses. Use when the user asks for feature ideas, "what to build next", "wow factor", latent demand, a roadmap, or a competitive gap analysis. Covers researching real pain, the painkiller-not-vitamin test, competitor gap-mapping, and filing the prioritized results as tracked issues. |
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
- 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.
- 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.
- 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)."
- Map the competitive gap. Compare against what competitors do and do not do; the gap is often where the latent demand sits.
- 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.
