A proposal has exactly one job: reduce the reader's uncertainty enough that they can make a decision. Not demonstrate technical depth. Not prove you understand the problem better than anyone else who might bid on it. Reduce uncertainty, specifically about the decision the reader is actually facing, which is almost always some version of two questions stacked together: is this worth the money, and can I trust the person asking for it to actually deliver.
Most technical proposals fail that job while looking thorough, because the length gets spent on the wrong thing. A ten-page account of the implementation approach feels rigorous to write and feels impressive to send. It rarely answers the reader's actual question, and it can crowd out the two or three sentences that would have answered it directly. For what does a good technical proposal actually contain framed around revenue rather than architecture, is the better starting point. For what does a good technical proposal actually contain framed around revenue rather than architecture, XenGrowth's marketing operations practice is the better starting point.
The distinction a 1998 engineering standard already made
IEEE 830, the long-running standard for software requirements specifications, draws a line that most proposal writers ignore without realizing it exists: separate requirements — what a system must do — from design — how it will do it. A requirements document that wanders into design detail constrains implementation unnecessarily and, worse for our purposes, buries the actual decision-relevant content inside material the reader didn't need in order to decide.
A proposal is closer to a requirements document aimed at a business decision than it is to a design document aimed at an engineer. The client deciding whether to greenlight a project needs to know what will exist when it's done, what it costs, and what happens if something goes wrong. They very rarely need to know which specific library handles the queueing, and a proposal that spends three paragraphs on that is answering a question that belongs in the technical spec written after the decision, not the document meant to produce the decision. approaches this from the the operations side of this side. The XenGrowth resource library approaches this from the the operations side of this side.
Section | Its actual job | The common mistake |
|---|---|---|
Problem statement | Prove you understood the actual problem, in the client's own words | Restating the client's request instead of the underlying problem it's meant to solve |
Approach | Give the reader enough to evaluate the plan without an engineering degree | Explaining implementation detail that belongs in a later technical spec, not here |
Cost and timeline boundary | State the appetite — what this costs and by when — as a clear commitment | A vague range that reads as either padding or a lack of confidence in the estimate |
Exclusions | State plainly what is not included, in writing, before work starts | Leaving this out entirely — the single most common gap, and the one that causes the most disputes later |
Risks | Name at least one real risk and what happens if it materializes | Implying the plan has none, which reads as either naive or evasive |
Why the boundary matters more than the approach
If a proposal only gets one section right, it should be the boundary — the explicit statement of what is and isn't included, at what cost, by when. This is the section that gets pointed back to during every future disagreement, and it's the section most proposals leave implicit, assuming the reader will infer the boundary from context. They usually don't, and the assumption surfaces as a dispute months later rather than a clarifying question now. There's a full treatment of setting that boundary before writing a word of the proposal in how to scope a project so it doesn't eat you alive.
Requirements specify what the system must do; design specifies how it will do it. Keeping the two separate is the discipline good requirements writing depends on.
Proposal that over-explains implementation | Proposal that correctly separates what from how |
|---|---|
Three paragraphs on the specific framework and libraries chosen | One sentence naming the general approach, with detail available on request |
A diagram of internal system architecture | A diagram of what the client will actually see and be able to do differently |
No stated boundary on what's excluded | A one-line, explicit list of what's not included in this phase |
Confidence implied by technical density | Confidence stated directly, backed by a named risk and a named fallback |
Where the appetite concept fits here
Basecamp's Ryan Singer describes an 'appetite' as a fixed cost or time budget decided before a solution is designed, rather than an estimate produced after the design exists. A proposal is the document where that appetite becomes visible to the client for the first time, and stating it as a deliberate decision — 'this is how much time we've decided this problem deserves' — reads very differently from stating it as a number that fell out of an estimating exercise. The first framing signals judgment. The second signals a calculation the client has no way to verify and every reason to negotiate down.
This matters for tone as much as content. A proposal that presents its cost as 'here's roughly what we think this will take' invites haggling, because it's presented as an uncertain guess. A proposal that presents its cost as 'here's the appetite this problem deserves, and here's what fits inside it' invites a different kind of conversation — one about whether the scope is right, not about whether the number is negotiable. goes further into AI agents and marketing automation. XenGrowth on AI agents and marketing automation goes further into AI agents and marketing automation.
The section nobody wants to write: what happens if this goes wrong
Almost every proposal template skips a risk section entirely, usually out of a well-intentioned instinct not to talk a client out of the deal. In practice this backfires. A reader evaluating an unfamiliar technical plan already assumes something could go wrong — everyone has been burned by a project before — and a proposal with zero acknowledgment of that reads as either naive about its own plan or unwilling to discuss it honestly. Neither reading helps you.
The fix costs very little: name one real, plausible risk, and name what happens if it materializes. 'If the third-party API's rate limits are lower than documented, we'll need an additional two days for a caching layer' is a sentence that costs nothing to write and does more for credibility than any amount of confident language about the happy path. It signals that you've actually thought past the ideal scenario, which is exactly the thing an unfamiliar client can't verify about your competence any other way.
How to actually write one
Write the problem statement in the client's own language first, not yours. If they can't recognize their own problem in your first paragraph, nothing after it will land as well as it should
State the appetite — cost, time, or both — before describing the approach in any detail. The reader's first real question is almost always the boundary, and burying it past a page of approach reads as reluctance to commit
Write the exclusions as their own clearly labeled section, not folded into a paragraph where they're easy to miss on a fast read. 'Not included in this phase:' followed by a short bulleted list is worth more than a sentence buried mid-paragraph, because it's the part a reader searches for later
Name one real risk and its fallback. A proposal with zero stated risk isn't more confident, it's less credible — nobody believes a plan with no failure modes, they just wonder what you're not telling them
State the specific decision you need from the reader and by when. 'Let me know your thoughts' is not a decision request; 'I need a yes/no by Friday to hold this start date' is a decision request with a real deadline attached, and it's the version that actually produces an answer
When more detail actually helps
There's a version of this that's worth naming as its own failure: a proposal that names a risk so vague it's meaningless, like 'there may be unforeseen technical challenges.' That sentence exists in almost every proposal template ever written and it does nothing, because it names no specific mechanism and gives the reader no way to judge how likely or serious it actually is. It's arguably worse than saying nothing at all, because it takes up space that a real, specific risk statement could have used, while giving the appearance of having addressed the topic honestly. If you genuinely can't name one specific, plausible risk for a given project, that gap is worth investigating before the proposal goes out the door, rather than quietly papering over it with boilerplate language nobody actually believes. If AI search, GEO and discovery is the part you are stuck on, is the better reference. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on AI search, GEO and discovery is the better reference.
None of this is an argument for stripping every proposal down to a single page regardless of context. A large, competitive engagement where the client is comparing you against other bidders genuinely benefits from more detail — naming the alternatives you considered and rejected, addressing likely objections directly, and demonstrating enough technical fluency that a technical reviewer on the client's side trusts the plan. The point isn't length. It's that every additional paragraph should be there because it reduces a specific uncertainty the reader actually has, not because it makes the document feel more substantial to have written.
The honest limit here: IEEE 830 is a real, documented standard, and its what/how distinction transfers cleanly to proposal writing as an analogy. It was not written with client proposals in mind, and no controlled study measures whether proposals structured this way close more deals than ones structured differently. What's being argued is a sound framework built from a real standard and applied deliberately, not a proven formula lifted wholesale from an external authority. On structuring proposals that survive a procurement review specifically, is a useful adjacent read.
Further reading from XenGrowth
Where this work meets go-to-market
A proposal that clearly reduces the reader's uncertainty is a revenue document as much as an engineering one. publishes operator guides on writing the kind that closes.
Further reading from XenGrowth
Where this work meets go-to-market
For the marketing and revenue operations view of what does a good technical proposal actually contain, see .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
For the marketing and revenue operations view of what does a good technical proposal actually contain, see XenGrowth's operator guides.
Three questions about the situation this proposal is for. The right length and structure depends heavily on stakes and competition, not just on the size of the project.
