Main idea

A product manager explaining a product opportunity to an assistant starts from an interlocutor who knows nothing about it, and who will fill in no gap out of politeness. You have to give the goal, the constraints, what has already been decided, what remains open — then start again when the result is not the one you expected, reformulate, sharpen.

That is where the exercise turns back on you. Re-explaining puts to the test what you thought you had understood: what stayed implicit has to be written down, and part of what you took for granted does not survive the writing. Where a colleague would have caught an approximation with their own context, the machine takes it at face value and returns an approximate result — no visible error, simply beside the point.

The assistant therefore does not compensate for vagueness, it amplifies it: if the context is vague in the head of the person describing it, the result will be vague, and the quality of the output becomes an indicator of the clarity of the input.

Why it matters

This turns work perceived as a chore of data entry into an exercise in verification. The time spent framing is not merely the price paid to get something: it is the only moment when you observe what you cannot yet put into words.

It also gives a different reading of a bad result. Before blaming the model, there is a diagnosis to make on what it was given — and that diagnosis is often more instructive than fixing the prompt.

Nuances and limits

The mirror does not reflect everything. A perfectly clear and perfectly wrong context produces a clean result, and the exercise says nothing about its correctness.

And an obliging assistant blurs the signal: if it produces something plausible from a vague instruction, the initial confusion no longer shows.

Open questions

• How do you tell a mediocre result caused by a vague context from a mediocre result caused by the model's limits?