Deep dives
DraftBefore · Research · 6 min
Domain research before building
A draft approach for learning enough about a domain without pre-building the answer.
Draft status: this is initial content, not reviewed domain expertise yet.
The first principle
Domain research at a hackathon is not academic completeness. It is reducing the chance that your team solves an imaginary problem.
The question is: what must be true for this project to matter?
Useful questions
- Who has the pain?
- When does the pain happen?
- What do they do today?
- Why is the workaround still bad?
- What data or workflow proves the pain exists?
- What would make the solution immediately useful?
- What would make it obviously unrealistic?
Fast evidence sources
- Sponsor documentation and challenge notes.
- Public workflows, forms, screenshots, or user forums.
- Short conversations with mentors or domain people.
- Existing tools and their negative reviews.
- A tiny manual test with real input data.
Draft output
By the end of research, the team should have:
- One user sentence.
- One painful moment.
- One current workaround.
- One product claim.
- One reason this weekend prototype can prove the claim.
If you cannot write those five lines, the team is probably still building inside fog.