Product thinking
Before you build anything, understand who it is for.
Five useful questions to bring people, not assumptions, into your product brief.
A problem is a better starting point than a feature list.
A request for an app, a portal or an AI assistant often begins with an important frustration. Before choosing the solution, ask what people are trying to do and what gets in their way.
1. Who is being asked to change?
Write down the people involved, including the people whose needs are easy to overlook. A staff member, a first-time visitor and a person using a screen reader may experience the same service very differently.
2. What happens today?
Follow the current journey. Look for repeated questions, workarounds, confusing handovers and information people have to provide more than once. Ask permission before recording research and avoid collecting details you do not need.
3. What would genuinely improve?
Describe the change in plain language: a person can find the right service without calling; a worker can understand a request without copying information; a learner can complete a task without feeling rushed.
4. What is the smallest useful thing to test?
A sketch, a short prototype or a conversation around a sample screen can reveal a mistaken assumption before it becomes expensive code. Choose a test that helps answer a real question.
5. What evidence will tell us to continue?
Agree on the signals that matter before the project grows. Completion, clarity, confidence and fewer avoidable errors are more useful than a long list of features. Treat early feedback as a reason to learn, not a reason to defend the design.