One-page project proposal

How to use it well

• →Cut everything that isn't the problem, the fix, the cost, and the payoff - a proposal that needs a second page is asking the reader to schedule a meeting instead of deciding.
• →Put a number on the problem and a number on the outcome. "This is annoying users" gets deferred forever; "1,200 tickets a month, projected to drop 70%" gets a yes or a no.
• →Name an actual date in the decision line. Without one, a one-pager that everyone agrees is "a good idea" quietly never gets approved.

Part by part

## Problem

Problem before solution, deliberately. A proposal that opens with what to build invites debate about the approach before anyone agrees the problem is worth solving.

## Cost and effort

Stated before the outcome, so the benefit is read against its price. Reversing them makes every proposal look worthwhile.

## Decision requested

The section that makes it a proposal rather than a document. Without a named decision, it circulates, gets nodded at, and nothing happens.

Please respond by {{decide_by}}

A date. A decision request with no deadline is deferred indefinitely, because deferring is always the cheapest response.

Common mistakes

• Leading with the proposed solution.

  Readers evaluate the approach before they have agreed there is a problem, so the discussion becomes technical when it should be about priority. Problem-first reorders the whole conversation.

• Omitting the decision requested.

  Turns a proposal into a document. People read it, agree it is interesting, and nothing changes — because nobody was asked for anything specific.

• Writing four pages instead of one.

  The length constraint is what forces the argument to be sharp. A long proposal is read by fewer people and decided on more slowly, which is the opposite of what it is for.

Questions