I have been on both sides of this. The projects that go wrong are rarely the ones where the engineering was beyond someone. They are the ones where two people had different pictures in their heads and neither found out until money had been spent.
What belongs in the brief
The problem, not the solution. "We need a LoRaWAN sensor" is a solution. "We need to know the tank level at forty sites, to within two centimetres, reported hourly, with no mains power and no site visits for five years" is a problem — and it may have a better answer than the one you had in mind.
The constraints that are real. Unit cost target and volume. Enclosure or form factor if it is fixed. Power source and expected life. Environment: temperature range, ingress, vibration, washdown. Which markets it is sold into, because that decides the compliance route. Any existing system it has to talk to.
What already exists. Previous boards, firmware, schematics, test results — including the ones that failed. Especially the ones that failed. An engineer who can see the last attempt starts three weeks ahead.
What done looks like. Is the deliverable a working prototype, a set of manufacturable files, a passed compliance test, or a product on a shelf? These are very different amounts of work and they are often used interchangeably in the same conversation.
The deadline that actually matters, and why. A trade show, a customer commitment, a funding round, a regulatory date. If a deadline is arbitrary, say so — knowing which dates are real changes how the work is sequenced.
What to leave out
Do not specify the MCU, the RTOS or the topology unless you have a genuine reason — an existing codebase, a supply agreement, a second source. Handing over implementation decisions as requirements removes the main thing you are paying for. If you do have a reason, state the reason rather than just the part number, so it can be honoured where it matters and questioned where it does not.
What you should be asked in return
A brief that comes back with no questions is a warning sign. Expect to be asked: what happens when it loses connectivity; what the worst realistic environment is rather than the typical one; who does final assembly and test; what the support period is and who provides support; whether there is a field-update path; what the consequence of a wrong reading is, because that changes the whole design; and who signs off the declaration of conformity.
If none of that comes up, you are talking to someone who intends to build what you said rather than what you need.
How to keep it honest
Agree the scope in writing and agree what a change costs before you need one. Ask for the work to be sequenced so that something useful exists early — a de-risked prototype of the riskiest part, not a beautifully documented plan. And ask, at the start, what the engineer thinks is most likely to go wrong. The answer tells you whether they have done this before.