On-delo Product Notes · 16 October 2026
1. Name a specific group of people
“Everyone with a phone” is too broad to guide design. Describe the people you have in mind in terms of a shared situation or task. Keep the description respectful and based on what you can observe or learn, rather than assumptions about age, income or ability.
Prompt: This product is for [people in a specific situation] who need to [task or outcome].
2. Describe the moment the problem happens
Write down what someone is trying to do, where the attempt begins, what gets in the way and what happens next. A concrete moment is easier to investigate than a broad topic such as “communication” or “education.”
Prompts: What was the person trying to do? What triggered the need? What made the task difficult, slow, confusing or unavailable? What did they do instead?
3. Record the current workaround
People usually have some way of dealing with a problem already: a conversation, a paper list, a call, a spreadsheet or simply leaving the task unfinished. A workaround reveals what people value and what constraints a new product must respect. Do not describe the current approach as “nothing” until you have checked.
4. Separate evidence from assumptions
Make two columns. In one, write what you have directly observed or heard from people doing the task. In the other, write what you currently believe but have not checked. This makes uncertainty visible and helps you choose what to learn next.
- Evidence: a specific example, repeated behavior, user quote or observed obstacle.
- Assumption: a guess about who will use the product, what they will pay, what device they have or how often the need occurs.
Use interviews or observation to understand context. Ask people to describe a recent real occurrence rather than only asking whether they like a proposed idea. Avoid collecting personal information you do not need.
5. Define a useful outcome
Choose a change that would matter to the person using the product. “Launch an app” is an output; “a person can complete this task without repeating the same information” is closer to an outcome. Write down how you would notice the difference and what evidence would show that the product has not helped.
Prompt: We will know the first version is useful when [observable result for the user], measured by [a proportionate way to learn].
6. Set a boundary around the first version
List the one journey that must work end to end. Then name what is deliberately outside the first version. A tight boundary reduces risk and makes it possible to learn from actual use before investing in optional features.
Copyable one-page brief
- People and situation: Who is trying to do what?
- Problem moment: When does the difficulty occur?
- Current workaround: What happens today?
- Evidence: What have we observed directly?
- Open assumptions: What do we still need to check?
- Desired outcome: What should become easier or possible?
- First journey: What single end-to-end task will we support?
- Out of scope: What can wait until we learn more?
- Next learning step: Who can we speak with or observe?
Use the brief as a conversation, not a verdict
A problem brief is a working document. Update it when new evidence changes your understanding. If the problem is not frequent, important or addressable with a digital product, that is useful information too. The best next step may be a simpler service change rather than more software.