Technical Proposal Structure
An arrangement for a written design proposal that lets reviewers engage with the decision rather than reconstructing the problem.
Most technical proposals open with the solution, which forces every reviewer to reverse-engineer the problem before they can evaluate anything. The result is review comments about the wrong things.
A structure that works, in order:
The problem, with evidence. What is wrong, for whom, at what cost. Quantified where possible.
Constraints and non-goals. What is fixed, and what this proposal explicitly does not attempt. The non-goals section prevents most scope arguments in review.
Options considered, each with its trade-offs — including the do-nothing option and its cost.
The recommendation and why, addressing the strongest objection to it directly rather than waiting for someone to raise it.
Consequences, including what becomes harder.
Open questions, which signals where input is genuinely wanted and focuses reviewers there.
Two practices that improve the outcome more than the writing does: circulate before the meeting, so the meeting is spent on disagreement rather than on presentation; and pre-socialise with the strongest likely objector, whose objection is better incorporated than defended against in public.
Length discipline matters: a proposal longer than a few pages is skimmed, and skimmed proposals are approved without scrutiny — which is the worst outcome for both sides.