Define the Problem Before the Model

A model idea can sound compelling long before the problem is clear. I have seen teams lose months optimizing a capability that could not be connected to a customer decision, a business outcome, or an accountable owner.

This is an original companion to Part 1 of the AI & PM Insights ML strategy series. The starting point is simple. Describe the problem in the language of the people who experience it.

Name the decision that needs help

A useful problem statement identifies who makes a decision, what information is missing or difficult to interpret, and what changes if the decision improves. It should make room for the cost of errors and uncertainty as well.

For example, predicting a category is not the product outcome. Helping an inspector decide which asset needs attention first may be. That distinction changes the data needed, the quality threshold, and the way success should be measured.

Look for evidence before enthusiasm

Talk with the people closest to the work. Review how the decision is made today. Find the delays, inconsistency, rework, safety exposure, or missed opportunity that creates a real cost. Then ask whether a prediction or recommendation would materially change that situation.

The goal is not to manufacture certainty. It is to establish enough evidence to justify a focused experiment.

Write down the boundaries

Every early ML effort benefits from clear limits.

• Who is the first user?
• What decision is in scope?
• What is out of scope for now?
• What happens when the system is unsure?
• What observable outcome would make the work worthwhile?

These boundaries protect the team from turning discovery into an open-ended research project. They also make it easier to decide when a simpler workflow, rule, or interface improvement is the better answer.