How to Brief a Developer So You Get What You Actually Need

Most frustrating software projects trace back to the same root cause: the brief described a solution, not the problem it was meant to solve.

“We need a button that exports to Excel” is a solution. The problem underneath it might be “our accountant needs this data in a format she can reconcile against invoices” — and if that’s the real problem, a CSV with the right columns might solve it better than a button, or the export might need to happen automatically rather than on demand.

A brief that leads with the problem gives a developer room to suggest a better solution than the one you had in mind, and it surfaces disagreements early — before code gets written — rather than at delivery, when a technically correct answer to the wrong question is the last thing either side wants to discover.

The practical version: for every feature request, write one sentence explaining what happens today without it, and one sentence explaining what should happen instead. The “how” can usually be left to whoever’s building it.