Write the what and the why, and leave out the how. A proposal should show your diagnosis, the outcomes, and three ways to work together. The moment it contains the plan itself, step by step, a client can hand it to somebody cheaper or run it internally.
Show your diagnosis and the outcomes, and describe the how at the level of what happens rather than how it is done.
Clients buy the interpretation and the result, and the executable plan is the part they are paying you for.
Read your last proposal and mark every sentence somebody could act on without you.
They want someone to make meaning of that information.
Leah Neaderthal, Smart Gets Paid
The line sits between naming what happens and teaching how it is done. Naming builds confidence. Teaching is the engagement.
| Shows value | Gives it away |
|---|---|
| "We start with stakeholder interviews across three teams" | The interview guide and the questions |
| "You'll have a prioritized roadmap by week six" | The prioritization framework, filled in |
| "We rebuild the onboarding sequence" | The sequence, written out |
| Your diagnosis of what is going wrong | The corrective plan, step by step |
A client reading the left column knows what they are buying and cannot execute it without you. A client reading the right column has a document their internal team can attempt on Monday.
The instinct behind the right column is worth naming, because it is generous rather than foolish. You want to prove you know what you are doing, so you show your work. Proving competence is what the diagnosis is for, and the same restraint applies on the call.
Clients need enough detail to answer four questions, and method depth is not one of them. What will this do for me, how does it work, how much does it cost, and how do we move forward.
"How does it work" is satisfied at the level of phases, timing and involvement:
That is a client's entire operational question answered, and none of it is executable without you. The deeper detail consultants add past this point is almost always reassurance for the writer, and it competes for attention with the sections that decide the outcome.
A client asking for a proposal early is asking for a conversation you have not had yet, and the move is to get the conversation rather than to write the document. Clients always want a proposal. That is not the same as the proposal being the right next step.
What to do instead:
Writing early is expensive twice: hours you do not get back, and a document built on guesses that then anchors the conversation. A proposal that arrives after real discovery takes an hour to write, because every section is already populated by what they told you.
A client who can execute your proposal without you was handed too much, and that is a document problem rather than a client integrity problem. It happens, and the fix is structural.
Step-by-step plans, filled-in frameworks, question sets, templates, and any section that reads like the first module of the work. The same instinct shows up on an unpaid call. If somebody could act on it Monday morning without calling you, it is liftable.
Your diagnosis is not liftable, because it is judgment rather than instruction. Your options are not liftable, because they describe scopes rather than methods. The outcomes are not liftable, because they describe a destination and not a route.
Most clients who take a proposal in-house were never going to hire anybody. The engagements you lose this way are usually engagements you did not have, and the document simply made the internal attempt easier. Write it tight anyway.
I want to separate two fears that feel identical and are not.
The first is that a client will steal your thinking. That is rare, and most organizations do not have the capacity to run your plan even when they hold it. The second fear is the real one: that you will not seem worth the money unless you show how much you know. That fear is what fills proposals with methodology, and it is the one costing you engagements.
Here is the thing. Depth of method is not what a client is evaluating. They are evaluating whether you understand their situation, whether the outcome is worth the money, and whether working with you will be straightforward. All three of those are demonstrated in the first section of the blueprint, where you tell them what you think is going on.
That section is your expertise on display, and it gives away nothing. Anyone can repeat back what they heard. Only you can say what it means.
So write the diagnosis with real confidence, describe the work at the level of phases, and put your energy into making the decision easy rather than making yourself look thorough.
A simple phase diagram helps a client picture the engagement and is not the same as handing over your method. Keep it at the level of names and sequence, without the contents of each phase. The test is whether somebody could run a phase from the diagram alone; if they could, it belongs in the engagement rather than the document.
Detail is easy to produce and rarely what decides a proposal, so matching it is usually the wrong response. A client comparing two documents is asking who understands the problem and who makes the outcome feel achievable. If you are losing to thicker proposals, look at the strength of your diagnosis rather than at your page count.
A redacted sample from past work is fine and often reassuring, because it shows quality without giving away a plan built for them. Keep it as an appendix rather than in the body, and make sure it is fully anonymized. What you never want to share is a finished artifact built specifically for this client's situation.
A few lines, and only if somebody besides you is delivering the work. Team bios at the front of a proposal are a habit inherited from agency documents, and they take up the space where your diagnosis should be. If credentials matter to this client, put them in an appendix and let the first page belong to their situation.