Frame the problem before modelling

Start with the decision

Understanding the problem starts with the setting in which the system will be used. What decision needs to be made? Who makes it, when, and what changes as a result? The constraints matter too: what information is available, what cannot be measured and which errors would be most costly.

These discussions establish a working definition of the problem. It remains open to revision, but gives everyone a shared basis for discussing the problem before expressing it as variables, rules or components.

Make the question testable

Good problem framing makes it possible to distinguish a meaningful improvement from an impressive demo. It identifies the signal to look for, the baseline for comparison and the evidence that would warrant revisiting the approach.

The aim is to make uncertainty explicit, rather than assume it can be eliminated. Technical decisions can then follow the context instead of being shaped by a solution chosen in advance.

Let the problem guide the implementation

Once the problem is clear, it becomes easier to choose appropriate data and methods. Some projects need a model. Others need search, a rule, an interface or a combination of simpler components. The implementation follows the need.

Understanding the problem before modelling is part of building. It keeps the work from moving quickly in the wrong direction.