How Long Should a Prompt Actually Be?
A quick question needs a sentence. Research or analysis needs a brief. The five-part brief that turns three paragraphs of hedged generalities into work you'd put in front of an owner — and why the 'why' does most of the lifting.
Match it to the task. A quick question needs a sentence. Research or analysis needs a brief.
Most people learn prompting through chat. You ask a question, you get a good answer, it works. So the next time, you ask for a market survey the same way — one line, same as always — get three paragraphs of hedged generalities back, and quietly conclude the tool isn’t ready for real work.
The tool was ready. The brief was not.
The test I use
If you would hand the task to a sharp new analyst with a one-line message, a one-line prompt is fine. If you would need to pull them into a room for ten minutes first, your prompt needs to carry those ten minutes.
If you’d need ten minutes in a room to brief a new analyst, your prompt has to carry those ten minutes.
That’s the whole calibration. Nobody writes a page-long brief to ask what time the airport shuttle runs, and nobody hands an analyst a five-word message and expects a board-ready comp-set analysis back. The mistake isn’t that people prompt too short. It’s that they prompt at chat length for work that was never chat.
The five-part brief
For anything involving research, analysis, or judgment, include all five:
- What you want. The actual deliverable, not the topic. “The Florida hotel market” is a topic. “A three-page market survey” is a deliverable.
- Why you need it. The audience and the stakes. This is the part people skip, and it is the part that does the most work.
- What the output should look like. Length, format, structure, tone.
- How to interpret the inputs. Which sources count, what’s authoritative, what to do with gaps.
- What to never do. The guardrails. Every one of these is a mistake you don’t have to catch on the back end.
Watch it work
Weak: “Give me a market survey of Florida hotels.”
Strong: “I need a market survey of the Florida hotel market to prepare for my annual investor meeting. Using only public sources of data, write a three-page report covering supply, demand, and rate trends across the major markets. Cite every figure with its source and date. Do not guess or estimate. If a number is not publicly available, say so and move on.”
Same request. Very different output.
The second version answers the questions the model would otherwise have to guess at on your behalf: how deep, for whom, how rigorous, what counts as evidence, and what to do at the edges. Those questions get answered either way. The only thing you control is whether you answer them or the model does.
Why “why” earns its place
Look at what one clause did in that example. “To prepare for my annual investor meeting” tells the model that the tone is serious, the numbers will be scrutinized, the audience is financially literate, and a confident wrong figure is far worse than an honest gap.
You never had to specify any of that. Purpose carries context that would take a page to spell out.
The inverse is just as reliable. Leave the purpose out and the model picks one for you — usually the safest, most generic one it can find, which is an explainer written for nobody in particular. That’s where the three paragraphs of hedged generalities come from. It isn’t the model failing to try. It’s the model writing for an audience you never named.
The guardrails are the cheapest part
Point five is the shortest thing to write and the one that saves the most rework. Do not guess or estimate. If a number is not publicly available, say so and move on. Two sentences that convert the worst failure mode — a confident, invented occupancy figure sitting in a deck in front of your owners — into the mildest one, a gap you can go fill before the meeting.
Operators already think this way. Every SOP you’ve ever written is mostly a list of what not to do, because the exceptions are where the cost lives. Same instinct, pointed at a brief.
Where this shows up in a hotel
The gap between chat-length and brief-length shows up in the same few places, over and over:
- Review responses. “Reply to this review” gets you something polite, generic, and faintly corporate. Name the property’s voice, the length ceiling, whether the responder is allowed to offer compensation, and what you’ll never put in writing — and you get something you’d actually publish under the GM’s name.
- Forecast commentary. The numbers should come from a model that runs the same way every month. The narrative around them is the judgment call. Say who reads it — an owner, an asset manager, a GM — and say what a miss costs, and the commentary changes shape entirely.
- Market and comp-set summaries. Say what counts as a source and what to do when a number isn’t public. Skip that, and the gaps get filled anyway. You just won’t be told which ones were.
- SOPs and training material. The brand standard, the reading level, the systems your team actually touches, and the steps a line-level employee is never authorized to take. Five lines of context, and the draft stops needing a rewrite.
None of this is prompt engineering in the trick-phrase sense. It’s the same briefing you’d give a competent new hire, written down once instead of explained out loud five times.
Try this on your next one
Take the last prompt that gave you a disappointing answer. Don’t rewrite the question — the question was probably fine. Just add the four things around it: why you need it, what the output should look like, how to treat the sources, and what to never do. Then run it again.
Most of the time, the model was never the problem. The brief was.
