A clear question.
A considered direction.

Describe the current activity in plain language. Who is involved? What is difficult? Where does a request, a decision, or a piece of information get stuck?

A useful problem statement identifies a need without prescribing a product. It also makes the constraints visible: available information, existing tools, responsibilities, and the consequences of a mistake.

Follow the path from an input to a result. Include the people, systems, and handoffs along the way. The aim is to make dependencies easier to discuss, not to create a perfect drawing.

Compare possible directions against the original question. Note the tradeoffs rather than hiding them. A simpler process may be more useful than a larger technical change.

Choose an assumption that matters and decide how a bounded example could help examine it. A paper flow, a visual model, or a small prototype can all make an abstract choice more tangible.

Keep the scope of the exercise explicit. Say which behavior is represented, what has been left out, and what the example cannot demonstrate. A prototype should answer a question rather than create the appearance of completion.

Compare what was learned with the original need. Look at clarity, usability, exception handling, and the practical work required to maintain the idea over time.

A review may support continuing, changing direction, or stopping. Each is a useful outcome when it is supported by a clearer understanding. Record the reasons so that the next conversation starts with context.