Start with a situation, not a solution
It is tempting to begin with a product idea and ask whether people would use it. That question can be useful later, but it makes the idea the center of the conversation. To learn about unmet needs, begin instead with a situation: a task people try to complete, a decision they face, or an experience that regularly creates difficulty. The goal is to understand what happens before proposing a better way.
Define the situation narrowly enough to investigate. “People struggle with organization” is broad; “people coordinating a shared household purchase” gives you a setting, participants, and a task to explore. Then ask who encounters it, when it arises, what a good outcome looks like, and what gets in the way. Different people may want different outcomes from the same task, so resist treating them as one group too early.
Look closely at what people already do
Existing behavior offers clues that opinions about a hypothetical idea may not. Ask people to walk through a recent example: What prompted them to act? What steps did they take? Which tools, people, or information did they rely on? Where did they pause, repeat work, make a compromise, or give up? Questions about a specific occasion make it easier to discuss the details of an experience.
Pay particular attention to workarounds. A handwritten note beside a digital system, a repeated reminder, or an informal handoff may indicate that the available approach does not quite fit. But a workaround is not automatically proof of a problem worth solving. It may be quick, familiar, and entirely satisfactory to the person using it. Ask what the workaround accomplishes, what it costs in time or attention, and whether the person would actually want to change it.
Explore needs without leading the answer
Conversations are more informative when people can describe events in their own terms. Instead of asking, “Would an app that does this help?”, try “Tell me about the last time you handled this.” Follow up with neutral prompts such as “What happened next?” and “What was difficult about that step?” If you share a concept too soon, people may focus on being encouraging or reacting to its features rather than explaining the underlying situation.
Use more than one perspective where possible. Someone who performs a task, someone affected by its outcome, and someone who supports the process may see different obstacles. You might also review materials people already use or, with permission, observe a relevant task. Be clear about why you are asking, respect privacy, and avoid collecting personal details you do not need. The aim is to understand the experience, not to gather information for its own sake.
Separate a meaningful pattern from an interesting anecdote
After each conversation or observation, record the situation, the person’s goal, what they did, the obstacle they encountered, and the consequence. Keep descriptions of what happened separate from your interpretation of why it happened. For example, “They checked three messages before deciding” is an observation; “They need a dashboard” is a proposed solution. That distinction leaves room for other explanations.
Compare examples for similarities and differences. Does the difficulty appear at the same point in the task? Do people face it only under certain conditions? Who has found an acceptable way around it? A need becomes more useful to work with when you can describe its context, the outcome people seek, and the limitation of existing options. Contrary examples matter too: they can reveal that your initial problem statement is too broad.
Write a problem statement before building
Summarize what you have learned without naming a product. A practical format is: “When [situation], [group] needs a way to [desired outcome] because [observed obstacle].” Treat this as a working statement, not a final verdict. Check it against the examples you gathered. If it describes only one person or depends on an assumption you have not explored, refine it and look for more relevant experiences.
Only then consider possible concepts. Generate more than one approach, including changes to instructions, timing, coordination, or an existing tool. For each option, ask what it would make easier, what new effort it might introduce, and how you could learn whether it helps. A small sketch or simple trial can expose misunderstandings before substantial development. The purpose of early exploration is not to prove that an idea is good; it is to find a problem that is understood well enough to address thoughtfully.
