Describe the situation first
A technology conversation often begins with a proposed solution: a new dashboard, an automated step, or a different application. That proposal may be useful, but it can also hide the need that prompted it. Starting with the situation creates room to compare alternatives.
Describe what happens today in ordinary language. Include the people involved, the information they use, and the point where the work becomes difficult. Avoid deciding too early that the difficulty belongs to a particular tool.
Separate a symptom from a need
A late report is an observable event. The reason it is late might be missing information, unclear ownership, or a review that happens at the wrong point. A new reporting interface would not necessarily address those causes.
A useful problem statement connects the observation to a need. For example: “The person preparing the weekly overview needs to know which source has not been updated, so that they can request the missing information before review.” This wording leaves several possible responses open.
Make the constraints explicit
Constraints are part of the question, not a list to be added after a preferred solution has been selected. Existing systems, available time, information access, and the cost of a mistake can all affect which direction is sensible.
Distinguish what is known from what is assumed. If the team does not know why an update is delayed, say so. A short conversation about the current workflow may be a more useful next step than a technical prototype.
Decide what would be useful to learn
A first exploration does not need to settle every question. It needs a clear learning objective. That might be whether a shared definition is understood, whether a new sequence makes sense, or whether an interface communicates the next action.
Write down the question the exploration is intended to answer. Then record what the exercise can and cannot show. This keeps a small concept from being mistaken for a finished solution.
Carry a clearer question forward
A focused statement is a working reference, not a permanent verdict. New information can change it. Returning to the statement during a review helps reveal whether the proposed direction still addresses the original need.
The practical habit is simple: describe the situation, name the need, expose the constraints, and choose one useful thing to learn. The result is a clearer conversation about technology, with more room for a considered decision.
This article offers a general perspective. It is not a report of a client engagement, a research finding, or a guarantee about a particular system.
Explore the working framework