Describe what is happening
Start with an observable situation and its practical consequence. Avoid defining the problem as the absence of the solution you already prefer. We need an app does not explain what is difficult, for whom or under which conditions. Write those details first. Mark what is confirmed and what comes from an untested impression. A good problem brief gives another person enough information to examine the situation without requiring them to accept your preferred answer in advance.
Distinguish a symptom from an explanation
A delayed response may be a symptom; an unclear process is one possible explanation. Identify alternatives before declaring a cause. Ask what evidence would help distinguish them and whether you are authorised to obtain it. Do not investigate colleagues or collect personal information simply to strengthen a brief. Use appropriate operational records and approved channels. The aim is to frame a problem responsibly, not to assign blame using a confident story built from incomplete information.
Define the intended improvement
State what a better situation would allow someone to do. Keep the objective separate from a specific product or technique. An illustrative study-group problem might be that participants cannot find the current task list; the desired improvement is reliable access to an agreed list, not automatically a new platform. This distinction preserves room to compare proportionate solutions rather than expanding the project because the proposed technology sounds interesting.
List the constraints honestly
Identify time, authority, access, resources and any relevant requirements. Distinguish a genuine constraint from a preference that could be reconsidered. Do not describe a desired budget or deadline as approved unless it is. Ask who can make decisions when priorities conflict. A brief should reveal where permission or clarification is needed rather than hiding those dependencies until a solution has already been announced. Uncertainty belongs in the document when it materially affects what can be done.
Invite correction before recommendation
Share the brief with the appropriate people through approved channels and ask whether it accurately describes their task. Different perspectives may reveal that two apparent problems should be separated. Record corrections and explain what changed. Do not treat consultation as an automatic endorsement of a future proposal. Only after the problem is clear should you compare options, including a small process change or maintaining the current arrangement where that is a reasonable alternative.
Try a solution-free first draft
Write a short problem brief without naming a product, vendor or preferred intervention. Include the affected task, evidence, practical consequence, desired improvement, constraints and unresolved question. Ask a reader to suggest two different possible responses. If the wording makes only one response imaginable, inspect whether you have smuggled a solution into the definition. Revise until the brief permits a fair comparison. This exercise is for developing analysis and communication; a real change still requires the approvals, safeguards and responsibilities appropriate to the organisation and the action proposed.
