How To Write A Proposal By Michael Larsen

Getting Past the Basics

Most people waste weeks on proposals that go nowhere because they focus on formatting before they understand what the client actually needs. I spent years watching teams pour hours into beautiful documents that got deleted unread. The Michael Larsen approach flips that. Instead of starting with a template, you start by mapping the decision-making structure behind the opportunity. Here is how it actually works in practice. You interview stakeholders, identify who has budget authority, who has technical authority, and who can quietly kill the deal. Then you reverse-engineer the proposal around those people rather than around your company logo. I still see this method referenced when people ask me about How To Write A Proposal By Michael Larsen, and honestly the core idea hasn't changed much since it came out. The framework is about alignment before content.

How To Write A Proposal By Michael Larsen

The method breaks down into a few concrete steps, but the order matters more than anything else. Step one is always the stakeholder map. Not a generic org chart. A map of influence and resistance. Who will read this? Who will never read it but has veto power? Who needs to feel heard even if they are not the decision maker? I remember one engagement where we followed the standard process and built a detailed proposal for a mid-size logistics company. Two weeks after submission, the deal stalled. I went back and realized we had mapped the procurement team perfectly but completely missed the VP of Operations, who was secretly opposed to the vendor change. The proposal had been technically sound and beautifully formatted. It was also written for the wrong audience. I learned to always include a direct conversation with the end-user side before drafting anything. Even a twenty-minute call saves you from rebuilding the whole document later.

The Core Structure

Once you have your stakeholder map, the proposal itself follows a fairly predictable skeleton, but the content inside each section shifts depending on who you are talking to. Larsen emphasizes that a single proposal rarely satisfies everyone. The trick is to make the document layered so that different readers find their relevant information without the whole thing becoming bloated. The executive summary comes first and should be skimmable in under two minutes. This is where most people fail. They treat it like a miniature version of the entire proposal instead of a standalone argument that someone with zero time can still appreciate. If the summary does not stand on its own, the rest of the document likely will not get read past page three. After that, you move into problem statement, proposed solution, scope, timeline, pricing, and terms. The problem statement is where you mirror back the client's language. Use their words for their pain points. This is not manipulation. It is proof that you listened. When prospects see their own terminology reflected in your document, the cognitive friction drops significantly and the likelihood of engagement increases.

Pricing and Scope

The pricing section is where beginners lose deals most often. You can present the most thorough technical approach in the world, but if the pricing looks arbitrary, the proposal dies. Larsen recommends anchoring your price to value rather than to your internal cost structure. This means framing the number around what the client stands to gain or lose, not around how many hours your team will log. A lot of people interpret this as inflating prices or being vague about deliverables. It is the opposite. You have to be more specific about outcomes, not less specific about costs. The format typically includes a clear line-item breakdown, but those line items are tied to business results. Phase one delivers X outcome for Y cost. Phase two delivers Z outcome for W cost. This makes it easier for the buyer to justify each tranche to their own leadership. I once worked on a proposal where the scope creep was invisible until we were two months in. The client kept treating certain elements as implicit inclusions because we never explicitly carved them out. What fixed it was adding a clear section titled what is not included right after the scope. That single addition reduced change-order disputes by roughly sixty percent on subsequent projects. It felt counterproductive to leave things out deliberately, but omission without explanation is worse.

Common Mistakes to Avoid

There are a few recurring issues I see regardless of the industry. The biggest one is leading with your company history instead of the client's situation. Your track record is background noise until you connect it directly to their problem. A sentence about your credentials earns attention only when it explains why a specific past result is relevant to the current opportunity. Another mistake is submitting proposals without a defined next step. Every proposal should close with a clear, low-friction action the client can take within forty-eight hours. This might be a signature block, a scheduling link, or a single question that moves things forward. Leaving the ball in their court without an explicit path forward is just polite ghosting. There is also a genuine limitation to this framework that does not get enough attention. It works well when there is a visible decision process and reasonable access to stakeholders. In highly regulated environments or deeply political organizations, the decision architecture can be opaque enough that even thorough stakeholder mapping misses key players. In those cases, you supplement the proposal with a pre-read briefing document sent directly to the likely veto holders before the formal proposal arrives. It is not ideal. It is situational.

A Practical Workflow

If you want to actually implement this, here is a realistic sequence. Day one is the stakeholder call. Day two is the problem statement draft. Day three is the solution outline. Day four is scope and pricing. Day five is the executive summary and formatting pass. That is a tight schedule, but it keeps the document focused because you are not polishing prose before you know if the strategy holds up. Most revision time happens on days three and four, not on day five. The document should run between eight and fifteen pages for most commercial proposals. Anything longer requires a companion deck or appendix. Anything shorter usually signals that you skipped the stakeholder mapping step. These are rough guidelines based on actual experience, not hard rules. A complex infrastructure project proposal might legitimately run thirty pages with appendices. A small service engagement might be three pages with a detailed quote attached. The approach described in How To Write A Proposal By Michael Larsen is not a magic formula that guarantees every submission converts. It is a structural way to stop guessing and start building proposals that match how decisions actually get made inside organizations. The difference between a proposal that sits in an inbox and one that gets a meeting is usually whether someone with authority can explain the value to their boss in under three minutes. Everything else is secondary.