The blank page is not the hard part. I have plenty of rough ideas. The hard part is the gap between a rough idea and a brief that someone else can actually work from.

A rough idea looks like this: "Something about how teams waste time in meetings."

A usable brief looks like this: a clear angle, a defined reader, a specific promise, a structure, and a note on what to leave out.

That gap is where most of my ideas die. Not because they are bad, but because turning a vague thought into a workable brief takes a kind of thinking that is easy to postpone. So I built a prompt for it. Not a prompt that writes the brief for me — a prompt that asks me the questions I would otherwise skip.

Here is the structure, the weak output it produced the first time, and the edits that made it usable.

The Task and the Conditions

What I was trying to finish: Turn a one-line rough idea into a brief I could hand to a writer, or use myself, without a second round of "wait, what is this actually about?"

Tools used:

• ChatGPT (Plus plan) — main brief-building prompt

• Claude (free tier) — second pass on the same prompt, to compare

Input I gave it: the one-line rough idea, nothing else at first

Time I spent: about 25 minutes, including two rounds of revision

What I did not give it: any employer, client, or internal project details. The rough ideas I tested this on were either invented or generalized versions of real ones.

The Prompt Structure

The prompt has four parts, and the order matters.

Part 1 — State the rough idea exactly as it is.
Not cleaned up. Not made to sound smarter. The messy version, because the mess is the information.

Part 2 — Tell it what you do not know yet.
This is the part most people skip. I write something like: "I do not know who the reader is yet. I do not know if this is a how-to or an opinion piece. I have not decided what the takeaway is." Naming the gaps tells the tool to help me fill them instead of guessing and moving on.

Part 3 — Ask for questions before answers.
This is the single most useful instruction in the whole prompt. Instead of asking for a brief, I ask the tool to ask me what it needs to know to build one. It usually comes back with five to eight questions, and two or three of them are ones I had not thought to ask myself.

Part 4 — Then, and only then, draft the brief.
Once I have answered the questions, I ask for the brief in a fixed format: angle, reader, promise, structure, what to leave out, and what would make this fail.

The full prompt, in the form I actually use:

"Here is a rough idea: [idea]. Here is what I do not know yet: [gaps]. Before you write anything, ask me the questions you need answered to turn this into a usable brief. Do not draft the brief until I have answered. When I do, give me: the angle in one sentence, the reader, the promise to the reader, a rough structure, what to leave out, and the most likely reason this piece fails."

The First Attempt (Weak Output)

The first time I ran this, I skipped Part 3. I asked for the brief directly.

What came back was a perfectly reasonable-looking document that was useless. The angle was a restatement of the idea. The reader was "professionals interested in productivity." The promise was "learn how to waste less time in meetings." The structure was intro, three points, conclusion. The "what to leave out" section said "keep it focused."

Every line was technically true and none of it helped. I could not hand that to a writer, because a writer would come back with the same questions I had. The tool had answered with the shape of a brief without doing the work of one.

That is the failure mode: a brief that describes the idea instead of deciding anything about it. A real brief makes choices. A weak brief restates.

The Revision Process

Round 2: Ask for questions first

I reran it with Part 3 in place. The tool asked me things like:

• Who is the reader, specifically — a manager, an individual contributor, or someone who runs meetings?

• Is the piece meant to diagnose the problem or offer a fix?

• What is the one thing you want the reader to do differently after reading?

• What have you already written on this topic, so this does not repeat it?

• Is there a real example you can use, or does this need to stay general?

Two of those I had not considered. The "what have you already written" question was the most useful, because it forced me to check whether this idea was actually new for me or a rerun.

Round 3: Answer, then ask for the brief

Once I answered, the brief got sharper. The angle went from "how teams waste time in meetings" to "the specific kind of meeting that should have been an async update, and how to tell." That is a piece someone could actually write. It has a boundary. It excludes things.

The "what to leave out" section finally had real content: no tool recommendations, no remote-work politics, no meeting-length statistics. That is the section that saves the most time, because it prevents the draft from drifting.

Round 4: The failure condition

The last section — "the most likely reason this piece fails" — was the one I almost cut. It turned out to be the most honest part. The tool said the piece would fail if it turned into a complaint about meetings rather than a decision rule for the reader. That was correct, and I would not have named it on my own.

What Still Needed My Attention

The time accounting: about 15 minutes of prompting, 10 minutes of editing. The real saving was not speed. It was that the brief made decisions instead of describing the idea.

The Weak Output vs. the Usable Brief

To make the difference concrete:

Weak brief (first attempt):

• Angle: How teams waste time in meetings

• Reader: Professionals interested in productivity

• Promise: Learn to waste less time in meetings

• Structure: Intro, three points, conclusion

• Leave out: Keep it focused

Usable brief (after revision):

• Angle: The meeting that should have been an async update, and the two-question test for telling

• Reader: An individual contributor who runs one recurring meeting and suspects it is unnecessary

• Promise: A decision rule you can apply before the next occurrence

• Structure: The symptom, the two questions, what to do instead, what to say to the team

• Leave out: Tool recommendations, remote-work politics, meeting-length statistics

• Failure condition: It becomes a complaint about meetings instead of a rule the reader can use

The second one I could hand to a writer. The first one I could not.

The Verdict

Keep it — this is one of the few prompts I use every time.

The value is not in the brief the tool writes. It is in the questions it asks before writing. Those questions are the thinking I would otherwise postpone, and postponing them is how rough ideas die.

What it is good at: surfacing the decisions a brief needs to make, and naming the failure condition I would not have named.

What it is not good at: knowing my existing body of work, knowing my reader better than I do, and making the final call on the angle.

The limitation to remember: a brief is a set of decisions. If the output only describes the idea, it is not a brief yet. Do not accept the first version — it will almost always be a restatement.

The Anonymized Version of This Prompt

"Here is a rough idea: [idea]. Here is what I do not know yet: [gaps]. Before you write anything, ask me the questions you need answered to turn this into a usable brief. Do not draft the brief until I have answered. When I do, give me: the angle in one sentence, the reader, the promise to the reader, a rough structure, what to leave out, and the most likely reason this piece fails."

Run it twice. The first output is the shape of a brief. The second one, after you answer its questions, is a brief.

Guardrails I Followed

• I did not paste any employer, client, or internal project details into the tool. The ideas I tested on were invented or generalized.

• I treated the tool's questions as prompts for my own thinking, not as answers.

• I did not accept the first brief. The first version is almost always a description, not a decision.

• I kept the failure condition section even when it was uncomfortable, because that is where the brief earns its keep.

The questions came from AI. The decisions in the brief did not.

Next in this series: Why "make this better" keeps producing nothing useful.

I tried it so you don't have to waste your afternoon.