WRT-02 · SEC. 05 Content & Writing

Proposal Draft From a Short Brief

Turn a short project brief into a structured client proposal or RFP response draft.

FORMAT: workflow
DIFFICULTY: intermediate
TIME: 20 min
TOOLS: universal
MODELS: any
COPIES: 0 so far

When to use this

A prospect sent you a brief or RFP and you need a first-draft proposal fast, with the right structure, before you spend real time customizing the specifics.

The pattern

Pastes as plain text

Step 1: Generate the skeleton.
"Read the brief I paste below and outline a proposal with these
sections: Problem Understanding, Approach, Scope, Timeline, Investment.
For each section, write 2-3 bullet points of what should go there based
on the brief. Do not write full prose yet. Paste the brief below this
line:"

Step 2: Review the outline. Correct any misread requirements or add
missing constraints (budget ceiling, hard deadline, must-have tech).

Step 3: Expand to full draft.
"Expand the outline from step 1 into a full proposal draft. Problem
Understanding should mirror the client's own language back to them,
proving we listened. Approach should explain the 'how' in plain
language, no jargon. Scope should be a bulleted list of concrete
deliverables, not vague promises. Timeline should use relative phases
(Phase 1, Phase 2) not fixed dates unless I gave you a start date. For
the rate and start date, write 'TODO: rate' and 'TODO: start date' so I
can fill them in myself."

Step 4: Read the draft against the original brief line by line.
Confirm every stated requirement is addressed somewhere in Scope.

Real example output

"Problem Understanding: You're maintaining two separate checkout flows for web and mobile, and every pricing change means updating both, which is where last quarter's discount bug came from. Scope: Unify checkout logic into a single shared service. Migrate web checkout to consume it. Migrate mobile checkout to consume it. Add a test suite that catches pricing mismatches before deploy."

Why it works

Generating the skeleton first lets you catch misread requirements before the model burns effort writing full prose around a wrong assumption. Mirroring the client's language in Problem Understanding is what makes a proposal read as heard rather than templated.