Prompting Guide
How to Prompt Claude to Write a Project Proposal
A proposal that gets approved is specific. A proposal that gets ignored is vague.
Anthropic's Claude is good at turning a rough idea for a project into a structured proposal with a problem statement, scope, timeline, and the kind of specific detail that gets a stakeholder to actually say yes. It isn't good at knowing your budget, your team's real capacity, or your organization's politics unless you tell it, which is why "write me a project proposal for X" tends to come back as something generic enough to belong to any company. The fix is giving Claude the real constraints up front: who's reading it, what you actually have to work with, and what decision you need them to make.
To prompt Claude to write a project proposal, give it the problem you're solving, who the proposal is for and what decision you need from them, your actual constraints (team size, timeline, budget range), and an instruction to structure the draft as a problem statement, proposed approach, scope, timeline, and success metrics. Paste in any background material, prior proposals, or notes you already have, and ask Claude to flag anything in the request that's too vague to turn into a specific plan.
Published
Free lesson · no account neededMeet ClaudeWhy Claude?6 minStart the free lessonKey Takeaways
- Say who the proposal is for and what decision you need them to make. A proposal for your own team to plan around reads differently than one asking an executive to approve a budget.
- Give Claude your real constraints: team size, rough timeline, budget range. A proposal built on invented constraints has to be rewritten the moment someone with the real numbers reads it.
- Ask for success metrics specifically, not just a description of the work. A proposal that doesn't say how you'll know it worked is harder to approve and harder to follow up on later.
- Paste in background material you already have: prior proposals, meeting notes, a rough outline. Claude organizes and sharpens what you give it; it can't invent the context behind your specific project.
- Read the scope section especially closely before sending it. A scope that's vaguer or broader than what you actually intend to do is the single most common reason a proposal causes problems later.
Copy and Paste
Prompts You Can Use Today
A first full draft from a rough idea
I want to propose [describe your project idea in a sentence or two]. This is for [who the proposal is for and what decision you need from them]. Here's what I actually have to work with: team of [size], timeline of roughly [timeframe], budget around [range, or 'not yet determined']. Write a draft proposal with a problem statement, proposed approach, scope (including what's explicitly out of scope), a rough timeline, and success metrics. Flag anything you had to guess at because I didn't give you enough detail.
Being honest about what you don't know yet, like budget, produces a more useful draft than inventing a number to fill the gap.
Turning a messy brain dump into a problem statement
Here are my rough, unorganized notes about a problem I want to solve: [paste your notes]. Turn this into a tight, two-to-three-sentence problem statement that explains why this matters and who it affects, without describing the solution yet. I want the problem framed clearly before I propose the fix.
Keep the problem statement separate from the solution; a proposal that jumps straight to the fix often loses the reader who isn't yet convinced there's a problem worth solving.
Defining scope, including what's out
Here's my proposed project: [describe it]. Write a scope section that states clearly what this project will and will not include, with at least three specific things explicitly called out of scope. I want to avoid the proposal being read more broadly than I intend.
An explicit out-of-scope list is often the part of a proposal that prevents the most confusion later.
Stress-testing a proposal before you send it
Read this draft proposal as if you were the stakeholder deciding whether to approve it: [paste your draft]. What questions would you have before approving this? Where does the timeline, scope, or success metric seem unrealistic or unclear? Be specific about what's missing, not just what's wrong.
This works best right before you send the proposal, as a final check rather than an early draft step.
Adapting one proposal's tone for a different audience
Here's a project proposal I wrote for my own team: [paste your draft]. Rewrite it for an executive audience who needs to approve the budget: lead with the business case and the cost, keep the technical detail brief, and move any implementation detail to an appendix section at the end.
The same project often needs two different versions depending on who's reading and what they need to decide.
The Structure
The five parts a proposal prompt needs
These five pieces turn a vague idea into something a stakeholder can actually act on.
A problem statement, before the solution
State the problem and why it matters before describing the fix. A reader who isn't yet convinced there's a problem won't engage seriously with a proposed solution to it.
Scope, including what's explicitly out
Say what the project will do and, just as importantly, what it won't. An unscoped proposal tends to expand in everyone's head to whatever they assumed it meant.
Real constraints, not invented ones
Give Claude your actual team size, rough timeline, and budget range, even if some of it is still uncertain. A plan built on invented numbers has to be redone the moment real ones show up.
Success metrics, stated plainly
Say how you'll know the project worked. A proposal with no success metric is harder to approve and, if it's approved anyway, harder to follow up on six months later.
Know Your Reader
The same project needs a different proposal for a different audience
A proposal written for your own team to plan around and a proposal written to get budget approval from an executive are doing different jobs, even when they describe the same project. The team version can go deep on implementation detail because the reader already cares about it. The executive version needs to lead with the business case and the cost, because that's the decision the reader actually has to make, and buried detail they don't need just delays the decision you're asking for.
Tell Claude explicitly who's reading and what decision you need from them. "This is for my team to plan the next quarter" and "this needs to get budget approval from a VP who doesn't know the technical details" point Claude at two different drafts, even for the identical project, and naming the audience up front saves you from writing one version and discovering halfway through that it's wrong for the actual reader.
If you genuinely need both versions, it's often faster to write the detailed team version first and then ask Claude to adapt it for the executive audience, rather than writing both from scratch. The underlying facts don't change; only what gets emphasized and what moves to an appendix does.
Common Mistakes
What makes a proposal get stuck instead of approved
These are the gaps that turn a reasonable idea into a proposal that sits unanswered.
A scope that's broader than you actually intend
If you don't state what's out of scope, readers fill in the gap with their own assumptions, which are often bigger than what you meant to propose. Say explicitly what this project will not include.
No stated decision for the reader to make
A proposal that doesn't say what you're actually asking for, approval, budget, headcount, a go-ahead to start, leaves the reader unsure what response you need from them.
Invented numbers standing in for real constraints
A timeline or budget Claude guessed at because you didn't provide one will read as confident even though it's fictional, and someone with the real numbers will notice the proposal doesn't match reality.
No way to tell later whether it worked
A proposal without success metrics is hard to approve with confidence, and if it does get approved, there's no agreed way to check in six months later whether the project delivered.
Using What You Already Have
Paste in your background material instead of starting from nothing
If you have a prior proposal for something similar, rough meeting notes about the problem, or even a half-finished outline, paste it in rather than describing the project fresh from memory. Claude can organize and sharpen material you already have far more reliably than it can invent the specific context, history, and constraints of your actual project from a one-sentence description.
This matters especially for the problem statement. If the problem came up in a meeting, in a complaint from a customer, or in a prior failed attempt at something similar, that context belongs in the prompt. A problem statement built only from your current summary of the issue tends to lose the specific detail that made the problem real and worth solving in the first place.
The same applies to constraints. If your organization already has a standard proposal template, a typical budget range for this kind of project, or an existing timeline convention, give that to Claude directly rather than letting it default to a generic structure. A proposal that already matches how your organization expects to see this kind of document gets read more seriously than one that reads as a template from somewhere else.
It's worth keeping a running folder of proposals that got approved at your organization, even informally, and pasting a successful one in alongside your own draft when you can. Claude can pick up on the pattern of what tends to land, whether that's a particular level of formality, a preference for short paragraphs over long ones, or a habit of leading with risk mitigation, and apply that same pattern to your current draft instead of defaulting to a generic structure that doesn't match what actually works where you work.
Before You Send It
What to check before the proposal goes to its reader
Read the scope section first and ask yourself whether it describes exactly what you intend to do, no more and no less. This is the section most likely to cause problems later if it's vaguer or broader than your real intention, because it becomes the thing everyone points back to once the project is underway.
Check every number against reality: the timeline, the team size, the budget. A confident-sounding plan built on a guessed number is worse than an honest "timeline not yet finalized," because the first one gets treated as a commitment the moment someone reads it.
The structure here gets you a strong draft quickly; the judgment about what your organization and your reader actually need from this specific proposal is still yours to apply before it goes out.
A clear proposal gets read. A vague one gets ignored.
The structure is reusable for every proposal after this one. Nightschool AI's free lessons walk through real workplace writing tasks with Claude, including the judgment calls around scope and audience.
Frequently Asked Questions
What's the most important thing to tell Claude before it drafts a proposal?
Who the proposal is for and what decision you need them to make. A proposal for your own team to plan around and one asking an executive to approve a budget need different framing, even for the same project.
Should I give Claude a budget number if I don't actually have one yet?
No. Say the budget isn't finalized rather than letting Claude guess at a number. A confident-sounding invented figure reads as a commitment the moment someone with the real numbers sees it.
Why does the proposal need an explicit out-of-scope section?
Without one, readers fill the gap with their own assumptions about what the project includes, which are often broader than what you actually intend. Stating what's excluded prevents that drift.
How do I write a proposal that works for both my team and an executive?
Write the detailed version for your team first, then ask Claude to adapt it for the executive reader: lead with the business case and cost, trim technical detail, and move implementation specifics to an appendix.
Can I use notes from a prior proposal or a meeting instead of starting fresh?
Yes, and you should. Paste in whatever background material you already have. Claude organizes and sharpens real material far better than it can invent the specific context of your project from scratch.
Why does the proposal need success metrics?
Without a stated way to measure success, the proposal is harder to approve with confidence, and there's no agreed way to check later whether the project actually delivered on what it promised.
How should I check a draft before sending it to a stakeholder?
Ask Claude to read it as the stakeholder would and list the questions they'd have before approving it. Then separately check every number in the draft against your real constraints before it goes out.
What if my organization already has a standard proposal template?
Give it to Claude directly rather than letting the draft default to a generic structure. A proposal that already matches your organization's expected format gets read more seriously than one that doesn't.
A proposal that gets approved starts with real constraints
The structure is reusable every time. Giving it honest numbers instead of guesses is the part worth doing right.