Pitch Deck or Business Plan: Which Document Do You Need?
Pitch Deck or Business Plan: Which Document Do You Need?
The request rarely specifies. "Send me something about the business." At that point the two documents you have names for — a pitch deck and a business plan — start to look interchangeable, like two packages for the same contents.
They aren't, and the difference isn't the number of pages.
Choose the object by what the recipient has to do with it. If they need to understand an opportunity in a conversation, they need a deck that selects and sequences an argument for that encounter. If they need to inspect how the business is expected to operate, they need the working plan behind it. If they've handed you an application form, they need whatever the form says, no matter which document you'd rather build. One business can genuinely need both at once. What it won't survive is being converted from one into the other by changing the file format.
Start with the recipient's job, not the format
Three jobs show up again and again, and each one wants a different object.
Understand an opportunity in a conversation. The reader wants to grasp what the business is, why it might work, and what to ask you next. This is the deck's job: choose the order in which a stranger can follow the idea, and leave out what doesn't serve that order.
Inspect how the business will operate. This reader wants the choices behind the numbers — what the business will actually do each week, what it assumes, what it depends on, and what happens when part of the assumption moves. That's a working plan's job.
Follow a specified application. A bank, a program, or a landlord's process may come with its own form, its own required statements, its own page limits. The instructions govern. A plan is whatever they asked for, plus whatever supports it.
When all you get is "send something about the business," ask two questions before you open a design tool: who reads this, and what are they deciding? Whether to keep talking to you is a different decision from whether your numbers hold up, and the answer tells you which object to build. Two sentences of email can save a week of layout.
The usual failure is choosing by what's closest to finished. If your deck is three-quarters built, the temptation is to answer every request with the deck — including the request to examine your assumptions. That favors your convenience over the reader's purpose, and the reader's purpose doesn't change because your file already exists.
The plan is a working document; the deck is a selected argument
The U.S. Small Business Administration's planning guidance describes a business plan as a tool for organizing and running a business, and it separates traditional plans from lean formats. That distinction is the useful part, because it breaks the assumption that a plan is defined by its length. A lean plan can be a few working pages. A pitch deck can run to thirty slides. Counting pages and slides tells you which is bigger, not which is which.
The work differs. A plan can hold operating choices, dependencies, assumptions, and enough supporting detail for someone to check them. It's allowed to be uncertain, and it's more useful when it records where the uncertainty sits. A deck selects: it decides what this reader, in this encounter, needs to understand, and in what order.
Neither one repairs missing evidence. If you don't yet know how many e-bike owners live within riding distance of your shop, no capacity slide answers that, and no carefully written plan section does either. A document organizes what you know. It can't promote what you haven't found out. Nor does a confident summary validate the assumptions underneath it — a number stated cleanly in front of an audience is not a tested number. Y Combinator's 2016 pitch guidance leans toward plain explanation: say what the company does and show a concrete account of how someone uses it. That's help with a presentation. It isn't a rule about which document any particular lender or investor will accept.
One assumption, carried through three objects
Here's an invented shop with invented numbers, used for the rest of this piece. The facts don't change between documents.
Riverside Cycle Repair — fixed facts
- Two repair stands.
- Stand A is staffed by one full-time technician, five days a week, eight hours a day: 40 stand-hours.
- Stand B is staffed by the owner, two afternoons a week, four hours each: 8 stand-hours.
- Repair time available: 48 stand-hours a week.
- A scheduled tune-up takes about 1.5 hours of stand time. That's the owner's estimate, drawn from the previous season's booking records. Nobody has timed the work.
- Capacity: 48 ÷ 1.5 = 32 scheduled tune-ups a week.
- The owner wants to add e-bike service. A first e-bike service takes about three hours, which is two tune-up slots. She doesn't know how many e-bike jobs she'd get.
Now the assumption — how long a tune-up really takes — in three objects.
In the working plan:
Capacity. Two stands give us 48 hours of repair time a week. A scheduled tune-up takes about 1.5 hours of stand time, which puts weekly capacity at 32 tune-ups. The 1.5-hour figure is an estimate from the previous season's booking records, not a timed observation. If tune-ups actually take two hours, capacity falls to 24 a week. E-bike service uses the same hours: a first service runs about three hours, so each one displaces two tune-up slots. Five e-bike jobs a week would consume 15 stand-hours and leave 33 hours, or 22 tune-ups. We don't yet know how many e-bike jobs we'd see, so we haven't decided whether to offer the service.
In the deck, on the constraint slide, said aloud:
Two stands. Forty-eight hours of repair time a week, and the work is scheduled in 1.5-hour blocks — about 32 tune-ups. That's the ceiling until we add a stand. E-bike service would come out of the same 48 hours.
In the one-pager:
Riverside Cycle Repair: two stands, 48 hours of repair time a week, about 32 scheduled tune-ups. The next decision is whether to add e-bike service, which would use the same stand hours and hasn't been scheduled.
Three levels of detail, one set of figures. The deck and the one-pager say "about" because they're spoken and skimmed; the plan shows the arithmetic. What mustn't drift is the underlying quantity and the status of the estimate. The plan is clear that 1.5 hours is a booking-record estimate, not a stopwatch average. The deck is allowed to leave that sentence off the slide, but it is not allowed to imply something fresher, and it is never allowed to make 32 into a measured fact.
Here's the mismatch that no file conversion can repair. Export the plan, one heading per slide. The capacity heading becomes a slide reading 32 tune-ups a week in large type. The estimate that produced it is gone. So is the e-bike trade-off. If the dependency survives at all, it survives as "E-bike service adds a revenue line with no new equipment" — which the plan doesn't say, and which contradicts the plan's own arithmetic, because e-bike jobs come out of the same 48 hours. The format didn't change the facts. The conversion changed what the document claimed. That's the real failure: not that you turned a plan into slides, but that the slides now assert something the plan denies.
You can absolutely build a deck from a plan. You just have to make the selection again, in the deck's terms, and check that every figure survives the trip.
Three requests, three deliverables
Same shop, three written requests — all invented, all plausible.
"Could we grab twenty minutes Thursday? I want to hear how the business works." A prospective advisor. This is the conversation job, so build the short deck: what the shop is, how the stand hours work, what the next decision is. It doesn't need the booking-records note. You should still be able to answer "how do you know a tune-up takes 1.5 hours?" out loud. A deck may leave the arithmetic off the page; it may not leave you guessing.
"Send the operating assumptions, and tell me what changes if e-bike service grows." A lender. This is the inspection job, so send the plan's operating section: the capacity paragraph, the basis and status of the estimate, the e-bike dependency, the sensitivity. If the lender hands you a checklist, the checklist wins — plenty of institutions have their own forms, and the plan becomes whatever they asked for plus what supports it.
"Just send me a one-pager before we meet." A counselor at a small-business center. One page, no more. It's a summary of the working plan, not a third business model, and it should be able to sit beside the plan without contradicting it.
In this case the plan comes first, because the other two are selections from it. That isn't a universal order — if the lender's request arrived first, writing the capacity paragraph would force the same decision the other two keep deferring.
Some cases stay open. "Send me something about the business" still means asking. So does a request that names a format you know is wrong for the job, like a fifty-page plan for a first conversation. Ask what the reader will do with it and who else will see it. If the honest answer is "I just want to understand it before we talk," that's the conversation job. If a form arrives, the form decides.
Once the deck is the chosen object, its section order is a separate problem — that's the startup pitch deck structure article's territory, and this one stops at the choice. If the deck is for an internal decision rather than an outside audience, the internal decision deck article takes over instead.
Before you build anything, write down three things: the object you're sending, the job the recipient has to do with it, and the facts both documents will share. Then check the third item again after you've built the thing, because that's where conversions quietly go wrong.
Neither document is more honest than the other. A plan is allowed to be uncertain; a deck is allowed to be brief. What makes them consistent isn't that they look alike. It's that a reader who saw both would find the same business in each.
Frequently asked questions
How do I choose between a pitch deck and a business plan?
Choose by what the recipient has to do with it. If they need to understand an opportunity in a conversation, build the deck that selects and sequences an argument. If they need to inspect how the business is expected to operate, use the working plan. If they have handed you an application form, follow what the form says. One business can genuinely need both at once.
Is the difference between the two mainly page or slide count?
No. A lean plan can be a few working pages, and a pitch deck can run to thirty slides. The work differs: a plan can hold operating choices, dependencies, assumptions, and supporting detail; a deck selects what a particular reader in a particular encounter needs to understand, and in what order.
What goes wrong when a plan is converted into slides by heading?
The conversion can change what the document claims. In the invented example, the capacity heading becomes “32 tune-ups a week” in large type, while the 1.5-hour estimate that produced it and the e-bike trade-off disappear. A slide might then assert something the plan denies. You can build a deck from a plan, but you have to make the selection again in the deck's terms and check that every figure survives the trip.
Do the deck and plan need the same level of detail?
No. Detail can differ by object: the plan shows the arithmetic and records the status of estimates, while the deck and one-pager may say “about.” What must not drift is the underlying quantity and the status of the estimate. The deck may leave a sentence off the slide, but it may not imply something fresher or turn an estimate into a measured fact.
What if the request only says “send me something about the business”?
Ask two questions before building: who reads this, and what are they deciding? If the honest answer is that they just want to understand the business before talking, that is the conversation job and calls for the short deck. If a form arrives, the form decides. Some cases stay open until you ask.