How to define a problem more clearly

"We need an app" sounds like a clear task. Someone can estimate development, choose the technology and start drawing screens. The problem the app should solve remains unknown.

Defining a problem requires describing a gap between what happens and what needs to happen. A solution can come later. Starting with one organizes the investigation around justifying a choice already made.

Consider a fictional company that receives orders through messages and loses some information before preparing deliveries. Its first proposal is to replace messages with an app. That might help. It might also transfer the checking work to customers without fixing the failure causing the losses.

Describe an incident before naming the problem

Choose a recent case and follow what happened. Who received the order? Where did they record its items? When did the information stop being available? How did the team notice it was missing?

"There is disorganization" is an assessment. "The order was forwarded without an address, and the team had to find the original conversation" describes an incident. The second statement lets you locate a stage of the process and examine other orders that followed the same path.

Look for successful deliveries too. Differences between cases may reveal something hidden by the general description: a form some people used, a check performed during one shift or a message forwarded only in part.

Avoid making the first case an explanation for every case. It gives you a starting point for more precise observation.

Separate the event from the hypothesis

The missing address is observable. The idea that it was missing because people were distracted is a hypothesis. The idea that an app would solve its absence is another.

Each hypothesis needs a different check. If the system requires searching several messages for an address, attentive people may still need the same effort. If the address is already in an accessible record, the problem may be the handoff between whoever receives the order and whoever prepares it.

This distinction helps prevent premature accusations. "The team doesn't communicate" can become a vague demand. Identifying that nobody knows who should check the data lets you discuss a specific responsibility.

Record interpretations as possibilities instead of folding them into the initial description. The investigation can then contradict them without appearing to deny a fact.

Define the result that matters

Solving the difficulty does not necessarily require eliminating messages or putting every task on one platform. The desired result might be that the team receives the information needed for each delivery without returning to the original conversation.

That formulation admits different solutions. A required field, confirmation before forwarding or a separate process for incomplete orders may be options. Compare their results, the effort of using them and the cost of maintaining them.

Ask who needs to experience the improvement. A tool can make administration easier and ordering harder for customers. Defining only an internal metric leaves that consequence out.

Set a boundary too. "Improve the whole operation" can include any task and makes it difficult to tell whether the intervention works. Starting with one type of order or one stage makes the investigation more manageable.

Check conditions before choosing

What prevents the company from solving this today? Perhaps order volume is too low to justify a custom system. Perhaps nobody has configured a tool it already pays for. Perhaps the team cannot request every detail at first contact because some information depends on a later conversation.

These conditions affect which solutions are feasible. Finding them early prevents comparing a simple but insufficient alternative with an ideal solution that cannot fit the context.

A provisional formulation could be: "For this type of order, delivery details reach the responsible team incomplete. We need to identify where they are lost and test a way to receive complete details while keeping ordering easy."

This identifies the behavior, the group of cases and the desired result while leaving causes open. New observations can expand the investigation without restarting the conversation.

Revise the formulation after investigating

The initial description can change. If complete data was lost during manual copying, the focus moves from collection to transfer. If orders arrive with different people and no shared queue, tracking their status may be the problem.

Reformulating belongs to the work. Record what prompted the change so you can distinguish a discovery from an arbitrary shift of priorities.

Use the problem investigation worksheet for a stuck case. Describe an incident, note a competing explanation and choose an observation that distinguishes the two. Then compare solutions for the problem you actually found.