Brand
Get all logo versions.
Download 
A project proposal is the document you write to get a piece of work approved: what it is, the problem it solves, the evidence that problem is real, and what success looks like. This one-pager asks eight questions in order, from description and problem through audience, what it looks like in the product, the experiment plan, and the ship date. Product and project managers write one before a project gets staffed.
These three arrive in order. A project proposal asks whether the project should exist, and argues the case to whoever approves it. Once approved, a project charter says what you're committing to: scope, success criteria, constraints, and who decides. A project plan then covers how the work happens, with tasks, resources and a schedule. The proposal is persuasion, the charter is authorisation, the plan is execution.
A project proposal is a document that argues a piece of work should happen. It describes what the project is, the problem behind it, the evidence that problem is worth solving, who it's for, and how you'll know it succeeded. Proposals come at the start, before a project is approved or staffed, and they're written to persuade whoever controls the budget.
Start with the problem, not the solution. Describe what's broken, then show evidence it's real: ticket volumes, lost deals, research findings. Define success as a number you can check later. Only then describe what you'd build, roughly, and when it would ship. Most weak proposals invert this and open with the feature, which turns the review into a debate about implementation.
Say you're proposing single sign-on. Problem: enterprise deals stall at security review. Why: four of the last ten lost deals named SSO. Success: no deal cites missing SSO within two quarters. Audience: IT admins at companies over 200 seats. What: a settings page for SAML. How: ship SAML first, measure, then add SCIM. When: first release end of Q3. That's a complete sample: eight sections, a few lines each.
One page, with headings that are questions. A reader should be able to scan the headings and know what the proposal claims. Keep each section to a few bullets rather than paragraphs, put the problem and the evidence above the solution, and finish with dates. Longer proposals get skimmed, which means the parts you cared about go unread.
Yes, and the eight questions barely change. A software project proposal puts the technical approach in the How section and the affected users in Audience. A website project proposal usually swaps the product sketch for a page or flow. A project management proposal or a business project proposal outside product tends to expand Why into a cost case, since the evidence is financial rather than behavioural.
