The reflex
The request is written and you could start. Yet the expected result stays vague enough that you hesitate between several ways of doing it.
The builder’s reflex
Ask what problem the work has to solve, and for whom. If the answer stays vague, make a quick version and show it.
Why
A request passes through several people. At each relay, a detail drops. Sometimes it is the one that changes the solution.
A customer cannot find their invoices. The request becomes “add a search”. Looking at one case, the team finds the invoices are attached to another account. The search would have shipped, clean and useless.
A first attempt is the fastest way to understand. With today’s tools it takes an hour: a prototype shown to the person who asked answers faster than a meeting. For what cannot be undone, a heavy commitment or a contract, clarify first.
If you are starting out, ask for a concrete example of the expected result. If you hand work over, give the why with the what. Work with no clear goal forces the other person to guess. A role too: if you cannot say what problem it solves, do not open it.
Try this
Before a task, write down your assumption:
I understand this has to let [who] [do what], because today [difficulty]. Is that right?
Send it before you start. If the answer is slow to come, make the one-hour version and send that instead. After the first attempt, compare the result to the goal and correct your reading.
To discuss
On which task would a clarification of the goal change our next decision?