CORE GUIDE
Customer problem research
Customer problem research gathers evidence about recurring user pain, current workarounds, consequences and willingness to change before a solo builder automates or markets a solution.
Mental model
Treat a problem as an evidence-backed pattern, not an idea. The strongest signal is a repeated costly behavior or workaround tied to a specific context, not positive reactions to a proposed feature.
Why it matters
AI makes building fast, which increases the cost of solving the wrong problem at high speed. For solo operators, a few weeks spent automating low-value demand can consume the same scarce attention needed for acquisition and support. Problem research creates a decision gate before implementation.
01
Collect behavior before asking for approval
Define a narrow customer segment, interview or observe recent concrete situations, and capture trigger, current workaround, frequency, cost and consequence. Look for repeated patterns across independent users and test whether they will spend time, money or workflow change to solve the issue. Keep solution language out of early questions so evidence is not shaped by your own idea.
02
Example: users praise an AI dashboard but keep using spreadsheets
A founder interviews ten operators and shows an AI analytics concept. Everyone says it sounds useful, but follow-up questions reveal their real recurring pain is reconciling exports from two systems before weekly reporting. A small reconciliation workflow attracts immediate trial use, while the dashboard idea is deferred because enthusiasm did not map to behavior.
Common failure modes
- Asking users whether they like the proposed solution instead of studying recent behavior.
- Generalizing from one loud request without checking frequency across a segment.
- Treating social engagement as equivalent to willingness to change workflow or pay.
Engineering heuristics
- Ask about the last concrete occurrence of the problem, not hypothetical interest.
- Record existing workaround, frequency and consequence for every interview.
- Require behavioral evidence before committing scarce solo-builder capacity.
Takeaways
- 01Problem evidence should precede automation and growth effort.
- 02Current workarounds reveal more than polite feature enthusiasm.
- 03A narrow repeated pain is more actionable than a broad attractive idea.
Reading evidence
This records actions you actually took; it does not claim mastery, proficiency, or certification.
Used in
This Concept is reused across these canonical learning paths.
Related concepts from the Knowledge Graph
These relationships come from the canonical graph, not a separate Guide taxonomy.