Skip to content

Writing a proposal the team can consent to

A proposal succeeds when every member of the project can read it and find no reasoned objection. These habits make that likely.

  1. What it does. The core, and for whom.
  2. Why. The signal: what raised it, ideally in the words of whoever raised it. A quoted customer sentence is worth more than your summary of it.
  3. At least one thing it will not do. This becomes a constraint, and it is often what makes a proposal safe enough to try.

If you cannot write all three, the proposal is not ready. Ask for what is missing first.

Decide where the idea belongs in the model you already have:

  • Already there, or already in review? Then this is not a new proposal.
  • An improvement to an existing capability? Replace that capability. Do not add a second one beside it.
  • Building on a proposal in review? Revise that one, or raise a new one that says it depends on it.
  • A new capability under the direction it serves.
  • A new direction, which can bring its first capabilities.
  • Not a product change at all, such as a campaign, an event or a deadline. It does not belong in the model.

If the team could agree to one part and object to another, split it. Split it too if one part has to come first, or if one part is much harder or less certain than the rest. Two small proposals that each pass beat one large proposal blocked by a single objection.

  • Titles your team would recognise, not a model’s phrasing.
  • One item per concrete behavior.
  • Each constraint once, at the level it applies to.
  • A description that says what and why, not everything about it.

Run Check. Treat each flag as a question for you, not a verdict. Rewrite if the flag is right. Acknowledge it if you have considered it and still want to proceed. See Proposals and revisions.

When you revise a proposal in review, mark the revision material if it changes what anyone agreed to. Carrying consent forward over a real change hands it approval nobody gave. Keep typo-level for typos.