From an idea to a problem you can actually solve

Most ideas arrive phrased as a solution: “I want a system that answers customers.” That phrasing is natural, and it is also the main reason projects stall in month three. A solution without a defined problem is a moving target — everyone at the table pictures something different, and there is no way to settle an argument.

Three questions that need written answers

Who, and at what moment in their day. Not “customers” but a support agent who opens a ticket and spends eight minutes digging through documents. The more specific the description, the clearer what the system must do — and more importantly, what it must not.

What the current solution is. Every problem already has a solution, even a bad one: a spreadsheet, a question in a group chat, the veteran everyone asks. That is your real baseline for comparison.

What success looks like as a number. Handling time, share of tickets closed without a human, minutes saved per week. If you cannot phrase a metric, the idea is still a feeling — which is fine, but then the next step is to investigate, not to build.

A one-page document

Before the first line of code, write down: the user and the moment, the current solution and its weakness, the success metric, three real examples of input and desired output, and a list of what will not be in the first version.

The three examples are the important part. They turn an abstract argument into a discussion about a concrete case. If they are hard to write, that is the finding: there is no agreement yet on what the system should return.