Build a Partnership Pitch Around Work Both Sides Will Actually Do
Build a Partnership Pitch Around Work Both Sides Will Actually Do
Most partnership decks arrive with the same furniture: two logos, an ampersand, a paragraph about shared reach, and a number for the audience you'd both touch. It is a handsome document. It is also, from the other side of the table, a request to do something nobody has specified.
The person reading it is usually the one who would have to assign the work. They are not weighing your enthusiasm. They are asking a narrower question: what would my team actually be asked to do, and how much of it would we be left to guess?
Here is the answer this article works toward. A partnership pitch earns consideration when it names the customer outcome the combination would change, gives each side a piece of the work with its status marked honestly, follows one customer task through the handoff, and asks for a small joint decision that can establish whether any of it deserves developing. Logos, audience overlap and the word complementary introduce a possibility. They cannot stand in for the work.
1. Name the outcome the collaboration would change
Begin with a person trying to do something.
Not "we serve four hundred institutions in the same sector." Not a Venn diagram of your two customer lists. Start with the task that is currently awkward, and describe what the proposed combination would make possible in a way neither organization is presently delivering. If you can state that in a sentence the other party could repeat to a colleague, you have the center of the pitch. If you can't, you have a mood.
A customer outcome is not the same thing as a partnership. "Make the collection searchable" is an outcome. A partnership is one route to it, and possibly not the best one. The pitch has to show why this is coordinated work rather than an ordinary purchase or a straightforward funding request. If the honest answer is that you want to buy something, send a request for a quote. If you want money, make a funding ask. A partnership proposal is for work neither organization would do alone in this particular form.
Which brings up the case where the useful outcome is genuinely unknown — which happens more often than decks admit. Then the next proposal is to find out, not to announce a partnership. "We think researchers would search this collection if the text were indexed, and we don't know whether they would. Would you spend a day with us finding out?" is a modest, answerable proposal. It is also more attractive than a launch announcement with nothing behind it.
Here is the example the rest of this article uses. It is invented for the exercise. Two fictional organizations: Northline, which hosts digitized archive collections and serves them through a viewer, and Cadence, which extracts metadata from files and builds search indexes. The customer is a fictional historical society, Ravensgate, that keeps its scanned letters with Northline. The outcome under discussion is narrow and checkable: a visitor can type a keyword or a date range and open a matching letter, instead of paging through boxes one at a time.
Nothing about that example is verified — not the capabilities, not the customer's interest, not the sample export or anything it turned up. It is a construction for showing how the parts of a proposal fit together.
2. Give each party a concrete contribution
For each side, name the capability, the people who would do the work, and the work itself. Then label it. Three labels are enough, and they are not interchangeable: existing, proposed, unconfirmed.
A capability page is not a commitment. Northline's export interface exists, and a 300-item sample has already passed through it. Whether Northline will run that export across the whole collection, at the volume and cadence the project would need, is a proposal Northline's own people have not yet accepted. Cadence can build an index, and it built one from the sample; ingest of the full collection is proposed, not proven. Ravensgate owns the descriptive information about its own letters, and the sixty items the sample turned up without a title or date are its to fill — no one has asked it yet.
| Contribution | Who | Status |
|---|---|---|
| File storage, viewer, export interface | Northline | Capability exists; a 300-item sample export has run; export at full-collection scale is proposed |
| Metadata extraction, index, query endpoint | Cadence | Capability exists and has run on the sample; full-scale ingest is proposed |
| Item ID-to-file-path mapping | Unassigned | Unconfirmed |
| Titles and dates for the letters themselves | Ravensgate | Not yet asked |
The distinction sounds pedantic until a project starts. A company can possess an ability and never agree to use it for your project, and no program label changes that. One vendor's own partner tooling separates a comparable pair, though not this exact pair. Microsoft's services co-sell process in Partner Center records a customer objective and a partner role as distinct fields in an opportunity — the objective is what the customer wants, the role is what the partner does in pursuing or delivering it. The shared property is only that a single record keeps what is wanted apart from what a party will do. That tells you two useful ideas are separable in one company's workflow. It tells you nothing about whether your particular combination would work, and it certainly doesn't convert anyone's public capability description into an obligation.
Write the table for your own proposal and leave the "unconfirmed" cells empty rather than filling them with hope. An empty cell is the most useful thing on the page: it names exactly what the next conversation has to settle.
3. Explain what happens where the contributions meet
This is where most pitches dissolve into a diagram with both logos floating above an arrow.
Follow one customer task all the way through. In the Ravensgate example, the work runs in two directions, and both need saying.
Building the index. The sample was run before this pitch was drafted, and it has been through the pipeline once: Northline exported 300 scanned letters from 12 boxes, with a manifest listing each file's path and whatever titles and dates the record already holds; Cadence ingested the export, extracted what it could, built an index, and stood up a query endpoint. The pitch reports what that run turned up, and the return path is where the proposal proves it is serious. In this case, the export preserved the box folder but dropped the series subfolder for two of the twelve boxes, roughly fifty items. Cadence's ingest flagged those records — the series field is empty — and the question now belongs to Northline's integration contact: re-export those two boxes with the subfolders intact, or confirm that the series labels were never in digital form to begin with. That is the difference between a question and a stall. The flag says what is missing and who can answer it.
A second problem turned up in the same run, and it belongs to a different party. About sixty of the three hundred items carry neither a title nor a date. That is not Northline's to fix. It is Ravensgate's collection, and it is precisely the kind of condition a pitch leaves in the gaps when nobody has run the sample first.
Answering a search. A visitor types a term into Northline's viewer. The viewer calls Cadence's query endpoint. Cadence returns matching items and short snippets, and the viewer opens the file. The dependency hiding inside those four steps is identifier mapping. Cadence derives its item IDs from filename stems — letter-0142. Northline's viewer opens files by full path — ravensgate/box07/letters/letter-0142.tif. Someone has to hold the lookup between them, and if two boxes both contain a file called letter-0142, the stem stops being an identifier at all. Neither party has agreed to own that mapping.
Then notice who faces the visitor. Northline's name is on the page. When a search comes back empty, the visitor contacts Northline, even though the cause may sit in Cadence's index. Northline would be carrying a support obligation it does not control. A diagram that puts both logos above a single search box has hidden exactly this.
4. Make the proposed work possible to challenge
Show where the joint route could fail, and show it before someone else does.
In the example, the route currently fails at two places. A 300-item sample is not a bulk export: the interface exists and the sample came through it, but authorizing an export of the full holdings, at the cadence this project would need, is a decision Northline has not made. And the identifier mapping may not be routine; it might be a small build on one side or both, and neither side has agreed to carry it. There is a third condition worth stating plainly: Cadence prices per item, the sample is 300 items, and nobody has counted the rest of Ravensgate's holdings. A successful sample says very little about a full collection.
Then invite correction. Give each organization a section titled something like what we believe your side would do, and ask them to edit it, strike what is wrong and add what is missing. A pitch that cannot be corrected can only be accepted or ignored, and ignoring is cheaper.
Keep customer benefit and partner benefit apart, because they are not interchangeable. The visitor gets a search box. Northline may get a reason for Ravensgate to keep its hosting contract. Cadence may get a new manifest format in its ingest library. Those are plausible private gains and none of them is the outcome. Complementary capabilities are a starting possibility, not a result, and nothing about the fit of the two parts justifies a promise of distribution, revenue or customer access. If you catch yourself writing that a partner will "bring" an audience, ask which named person has agreed to bring it, and what they would actually send.
5. Ask for a bounded collaboration decision
End with the smallest real activity that would establish whether this deserves to go further. Not a memorandum of understanding. Not a letter of intent. A defined piece of work with an answer at the end of it.
For Northline and Cadence, that is a half-day joint review: one engineer from each side plus someone from Ravensgate, working from the sample run with three questions on the table. Will Northline authorize an export of the full holdings, at what volume and cadence, and who inside Northline can say yes? Who owns the identifier mapping between Cadence's item IDs and Northline's file paths, and does it require a build either side has to schedule? And who at Ravensgate supplies titles and dates for the sixty items that have none? The written output is a short decision list: the fifty items whose series label is missing, the sixty items needing descriptive metadata, and the mapping — each with a named owner. That document is worth more than another deck, and it costs an afternoon.
Be explicit about what the review does not decide. Pricing, commercial terms, delivery commitments, data handling, and whether the partnership happens at all belong to the people who would sign for it. A proposal that tries to settle those in the first meeting invites the other side to defend itself instead of investigating.
And leave room for no. If the review shows the export cannot be authorized at the needed scale, or the mapping is a bigger build than either organization wants right now, that is a genuine result. It cost half a day and it prevented two quarters of a project that was never going to ship.
The measure of a partnership pitch is not whether the other party admires it. It is whether they can tell you what their team would do, where it would break, and what they would need to know before deciding — and whether your document left them enough space to say so. Complementarity is where you begin. The work is what you hand across the table.
Frequently asked questions
What does a partnership pitch need beyond logos and audience overlap?
It needs a named customer outcome the combination would change, a concrete contribution from each side with its status marked honestly, one customer task followed through the handoff, and a small joint decision that can establish whether the work deserves developing. Logos, audience overlap, and complementary capabilities introduce a possibility; they cannot stand in for the work.
In the Northline and Cadence example, what did the sample run reveal?
Northline exported 300 scanned letters from 12 boxes with a manifest. The export preserved the box folder but dropped the series subfolder for two boxes, about fifty items, leaving the series field empty; Cadence flagged those records, and Northline's integration contact must re-export or confirm the series labels were never digital. About sixty items also had neither a title nor a date, and those belong to Ravensgate. Full-scale export is proposed, not authorized, and the identifier mapping is unassigned.
Why use status labels existing, proposed, and unconfirmed?
A capability page is not a commitment. Existing means the ability is there; proposed means a decision a party has not yet accepted; unconfirmed names exactly what the next conversation must settle. Leave unconfirmed cells empty rather than filling them with hope, because an empty cell is the most useful thing on the page.
What is the proposed bounded collaboration decision?
A half-day joint review with one engineer from each side plus someone from Ravensgate, working from the sample run. It asks three questions: will Northline authorize a full-holdings export, at what volume and cadence, and who inside Northline can say yes; who owns the identifier mapping and does it require a build; and who at Ravensgate supplies titles and dates for the sixty items that have none. The output is a short decision list with named owners. It does not decide pricing, commercial terms, delivery commitments, data handling, or whether the partnership happens.
What does the identifier mapping problem show?
Cadence derives its item IDs from filename stems such as letter-0142, while Northline's viewer opens files by full path such as ravensgate/box07/letters/letter-0142.tif. Someone must hold the lookup, and if two boxes both contain a file called letter-0142, the stem stops being an identifier. Neither party has agreed to own that mapping, and Northline's name is on the page, so Northline would carry a support obligation it does not control.