Partner Research Report Playbook

Do not start by asking what report to make

Most joint reports begin with the wrong question. Two companies like each other, someone says "we should do something together," and the conversation goes straight to format, page count and cover design. Nine months later there is a PDF with two logos on it, a few hundred downloads, and no way to tell what either company actually got.

Start somewhere else. What does Partner A need? What does Partner B need? Where do those needs intersect? What asset could serve both? And what research would produce something neither side could easily have made alone?

This playbook is deliberately industry-agnostic and stack-agnostic. It assumes only that two organisations want to create something neither would create alone, and that someone has to own the operational reality of making that happen.

The whole thing in twelve questions

The short version. If a partnership conversation is live and you need one screen, this is it — twelve questions in order, each of which stops the project if the answer is missing.

1. Why together? What does each side bring that the other does not have?
2. What exactly does A get, and what exactly does B get?
3. What market question are we settling?
4. What data do we need, and where does it come from?
5. Who does what, pays for what, and answers for what?
6. Who promotes this, where, and how hard?
7. What precisely gets built?
8. How do we deliver the research and the production?
9. How do we make publication an event rather than another PDF?
10. How does the report reach sales, ABM and pipeline?
11. How do both teams work from the same project context?
12. Did we make a one-off PDF, or intellectual property we can build on?

Questions 1–6 belong to design, 7–8 and 11 to planning, 9–10 and 12 to execution. Nothing below this line is more important than getting these twelve answered.

Three phases and two gates

The process has three phases, and the gates between them are the point. A gate is a moment to consciously kill or redesign the project — not a formality to wave through.

Not every good brand is a good partner

A partner has to bring at least one thing the other side does not have. Fill this in for every candidate, and pay attention to the advantage column — that is where the real complementarity sits.

Four configurations, two of which are worth doing

Also write down what this partner does not give you, and how you intend to cover that gap. A partner who is strong on distribution and empty on data is still a good partner — as long as somebody has thought about where the data comes from.

The topic test

It is not enough for a topic to be interesting. It needs a business reason to exist. Tick what is genuinely true — not what you hope will be true once the research is done.

Five out of seven is the pass mark. Below that, the honest move is to narrow the topic rather than start the research and hope the analysis rescues it.

Same subject, three levels of precision

Most weak topics are not wrong, just unfinished. They name a subject area and stop. Keep sharpening until a reader can tell who was studied, what the unit of analysis is, and why the answer might be surprising.

Each partner states its own value, separately

Do this step apart, not together. Partners almost never have identical goals — and they do not need to. One asset can serve two different objectives, but only if both objectives are written down.

Eight sources of value

Few companies need all eight. Each side should have at least two that are real.

The operating contract

This table is the real contract of the partnership, whatever the signed agreement says. Fill in every line — including the ones where a contribution is zero, because those are the lines that cause arguments later.

Total project investment is counted in four currencies, not one: cash, people-hours, paid media and audience access. A partner contributing no cash but a 40,000-person list is contributing more than a partner writing a cheque. If the totals come out visibly uneven, go back to exposure and make the visibility split honest.

Seven research models

Pick one primary model — occasionally two combined. This choice determines how hard your report is to copy. Declarations are cheap to reproduce; operational data is not.

Do we actually have the data?

Eight control questions, asked before the model is chosen rather than after. A "no" on any of the first four usually rules out models B and C.

Partial data is the common case, and it is not a problem. Existing data plus a survey plus a handful of expert interviews is model C, and it usually produces the strongest report of the three.

Respondent acquisition is a GTM motion

Getting responses is not a favour you ask on LinkedIn. It is a campaign, and it needs the same structure as any other: an ICP, a target, channels, a message, an owner and a KPI.

Set a minimum sample before you start, and treat it as real: below that number, you do not publish. Split the target explicitly — 100 from A, 100 from B, 50 from paid and partners — so that a shortfall has an owner rather than becoming everyone's problem in week six.

Lead partner and exposure architecture

Decide this before any work starts — not after the cover has been designed. Once the report is out, nobody can renegotiate whose logo is first or who receives the leads.

The exposure ledger — sixteen positions

Every line needs an unambiguous answer. An empty cell here is a conflict scheduled for the week before launch.

• "We'll sort the cover out later."
• "Let's see how many leads there are first."
• "We'll figure out the landing page when we get to it."

Design gate

Eight things must be known. If any one of them is still fundamentally unclear, this is not a delay — it is a no-go or a redesign. Killing a project here costs a meeting. Killing it in month three costs a quarter.

The team should see it before they build it

"A report, roughly 30 pages" is not a specification. Write down what actually gets built: length, formats, the interactive element, the number of charts, whether it is gated, which languages. Then plan production against that.

A report is not one asset. It is a source asset from which an entire content system is produced — and knowing that upfront changes how you plan.

Nine roles, one name each

One person can hold several of these. But every function needs a named owner, because "the marketing team" is not an owner.

RACI

R does the work, A answers for the result and approves, C is consulted, I is informed. Exactly one A per row — that is the whole discipline.

Plan from the launch date backwards

Not from today forwards. Fix T0 first, then derive everything else — it is the only way the uncomfortable dates surface while they can still be changed.

Ten milestones instead of one date

A single launch date tells you nothing until it is too late. Gates do.

Distribution commitments

This is one of the most important pages in the playbook. Each partner declares a minimum level of exposure before the project starts — countable, channel by channel. Without it, "partnership" ends at "we shared your post."

Track committed against ready during the project, not after it. "A: 9 of 10 ready, B: 4 of 10 ready" is a conversation you can still have usefully at T-2 weeks. On launch day it is just a grievance.

What happens to the interest after launch

A RevOps playbook does not end at impressions. A download is the start of a process, not the end of one.

Existing customers route to the account owner before anyone contacts them. Partner accounts route per the rule you chose below.

Partner lead rules — pick one before launch

Measurement across five levels

Set targets at planning time and fill in results after launch. A framework with no numbers in the target column is a wish list.

The strategic level is the one most teams skip and most often regret skipping. A report that produced twelve leads but three inbound partnership conversations and a conference slot was not a failure — it just did not pay out in the column everyone was watching.

Eight risks that actually happen

Score probability and impact 1–5; anything above 12 needs an active mitigation with a named owner and a date, not just a row in a table.

One shared project memory

There should never be a situation where one person's AI assistant holds different facts about the project than another's. The fix is not a better prompt. It is a canonical context pack that anyone on either side can paste into any tool and immediately be current.

Seven rules at the top of every session

1. Read all canonical project files before working.
2. Do not invent research findings.
3. Use only the approved dataset and sources.
4. Mark assumptions explicitly.
5. Respect the agreed partner exposure rules.
6. Check the decision log before proposing structural changes.
7. Treat current status as the current state of the project.

The setup is stack-agnostic. It does not require particular software — it requires five functions to have an unambiguous home: a single source of truth, an async channel, a formal decision channel that feeds the decision log, a task layer with owner and deadline, and email reserved for external and formal approvals. Email is not a project management system.

Running the research

Kick-off is not a brainstorm. The design is already done — the meeting confirms objectives, roles, milestones, dependencies, approval paths and sources of truth, and then everyone goes to work.

From here the discipline is about data quality, not ideas. Monitor weekly: responses, responses per day, contribution by partner, segment distribution, completion rate, and which segments are missing.

Dataset lock

There has to be a formal moment where the data freezes. After the lock: nothing changes, every chart uses the same version, any AI in the production chain works only from the approved dataset, and every insight can be reproduced. Without a named lock, you will find two charts in the same report built on different extracts — usually after it is published.

A percentage is not an insight

"63% of firms use AI" is a number. An insight has a business consequence. Every headline finding should carry all five layers, and if one is missing, it is not ready to be a headline.

This is also why the insight workshop exists, and why it happens before anyone starts writing. Both sides sit with the data and answer: what is surprising, what contradicts what we believed, what is contentious, what would interest a journalist, what would interest a customer, and what belongs on page one.

Claim registry

Every number that appears on the cover, in the press release, in social or in a sales conversation goes on one list, with one source and one approved version.

Pre-launch QA

Thirteen checks. You do not go to market with an open item on this list — and each one has a named checker, because "someone looked at it" is how a broken form reaches launch day.

Sales should meet the report before the market does. Thirty minutes is enough: why it exists, the five key insights, who it matters to, how to use it in a conversation, and which discovery questions come out of it.

Make publication an event

A launch spread across one afternoon reads as a PDF drop. A launch with phases reads as something happening in the market.

Insight drip

Do not publish every finding on day one. Spread the best data across twelve weeks: main report at week 0, insight #1 at week 1, insight #2 at week 2, webinar at week 3, insight #3 at week 4, expert article at week 6, customer perspective at week 8, and an update or mini-benchmark at week 12.

Executives on both sides should amplify separately, and differently. The CEO, the CTO, the head of engineering and the research lead each read the same data and reach a different emphasis — that is four posts, not one post shared four times.

The report as conversation infrastructure

This is where the project either becomes a GTM asset or stays a marketing campaign. The test is simple: six months later, is anyone still using it in a conversation?

Score the partnership, not just the report

Thirty to sixty days after launch, both sides review together: what each company generated in reach, which insights worked, what leads appeared, which segments responded, and what you learned about the market. Then score the collaboration 1–5 on ten criteria.

Then decide the next asset deliberately, on evidence rather than on team fatigue: stop, next edition, a recurring barometer, a webinar series, a benchmarking tool, a dataset, an event, or a research community.

Five arrangements that work in the market

Real partnership structures from the Polish IT market, shown as models rather than as an assessment of the publications themselves.

What all five share: in every case the partner brings something the other side does not have. None of them is two logos on a PDF.

These examples are illustrative. They are included to show the shape of the collaboration model, not to evaluate the specific publications, and Revenue Puzzles has no involvement in them unless stated elsewhere on this site.