Research
Understand before you build.
Why Research Comes First
Research is the act of understanding the problem before you start solving it. It sounds obvious, but the gravitational pull of building is strong — especially when you have AI tools that make building fast. The faster you can build, the more tempting it is to skip the understanding.
But speed without direction is waste. You can build an entire application in a weekend and discover on Monday that nobody needs it. Research is how you avoid building the wrong thing fast.
Research does not mean spending months in analysis paralysis. It means spending focused time understanding: Who has this problem? How do they currently deal with it? What would make their life better? You can do meaningful research in an afternoon.
The most expensive feature you will ever build is the one nobody uses. Research is cheap. Building the wrong thing is not.
Desk Research
Start with what already exists. Before you talk to anyone, look at the landscape.
Competitive analysis: Who else is solving this problem? What do they do well? What do they get wrong? Use their products. Read their reviews. Their one-star reviews are a goldmine — they tell you exactly what frustrated users wish was different.
Community research: Find the forums, subreddits, Discord servers, and social media groups where your audience talks. Read their complaints, questions, and workarounds. What do they struggle with? What language do they use?
Existing data: If you are improving an existing product, look at analytics. What pages do people visit most? Where do they drop off? What do they search for? Data does not tell you why, but it tells you where to look.
Talking to People
Desk research tells you what. Talking to people tells you why. There is no substitute for direct conversation with the people who have the problem you are trying to solve.
You do not need a formal research lab. Five conversations of 20 minutes each will reveal patterns that no amount of googling will surface. The magic number is actually five — after five interviews, you start hearing the same themes repeated.
The rules: ask open-ended questions ("Tell me about the last time you..."), listen more than you talk, do not pitch your solution, and pay attention to what people do, not just what they say. "I would definitely use that!" is not validation. People are polite. Actions are honest.
The Right Questions
Good research questions are about behavior, not preferences. You want to understand what people actually do, not what they think they would do.
"Tell me about the last time you organized your recipes." This is concrete. It triggers a specific memory. The person will describe real behavior, real frustrations, real workarounds.
"Would you use an app that organizes recipes?" This is hypothetical. The answer is almost always yes, and it tells you nothing. Nobody can accurately predict their future behavior.
"What is the hardest part of [the problem]?" This reveals pain points. "What have you tried?" reveals existing solutions and their shortcomings. "What would make the biggest difference?" reveals priorities.
Research with AI
AI tools can accelerate desk research significantly. You can ask Claude to summarize competitive landscapes, identify common pain points in a category, analyze review patterns, or draft interview guides.
But AI cannot replace talking to real people. It can synthesize existing information — things that have already been written. It cannot tell you about the specific frustration your target user felt last Tuesday, or the workaround they invented that nobody has documented.
Use AI for the preparation: "What are the top five complaints about existing recipe management apps based on app store reviews?" Then use conversations for the insight: "What specifically frustrates you about how you manage recipes now?"
Documenting What You Find
Research is only useful if you capture it. You do not need a formal report. You need a document that your future self (and your AI agent) can reference.
Write down: the problem in one sentence, who has it, how they currently deal with it, what frustrates them about their current approach, and what success looks like from their perspective.
This document becomes the foundation of everything that follows — your JTBD statements, your feature decisions, your prompts to AI agents, your eventual marketing copy. Good research compounds.
Research a Problem
Pick a problem you want to solve (or a product category you find interesting). Spend 30 minutes on desk research: look at three competing products, read their reviews (especially negative ones), and find one community forum where people discuss the problem. Write down the top five pain points you discovered. Now write three interview questions you would ask a real user. If you can, actually ask someone — a friend, a colleague, a family member who fits the audience. Compare what they say to what you found online.
Go Deeper
- Just Enough Research by Erika Hall — The best book on practical research for builders. Short, opinionated, and actionable.
- The Mom Test by Rob Fitzpatrick — How to talk to customers without getting lied to. Essential reading on interview technique.
- Nielsen Norman Group: User Research Methods — A comprehensive overview of when to use which research method.