You're excited about a potential collaboration. The partner organization does amazing work. Their mission aligns with your research. The first conversations went well.

So you start drafting the proposal. You write what you'll contribute: your lab's expertise, your students, your analytical capabilities. Then you write what you assume they'll contribute: community access, program infrastructure, participant recruitment.

You send them the draft for review. They say it looks fine. The proposal gets submitted.

Six months later, you get funded. And that's when you discover the problem.

The "program infrastructure" you assumed existed? It's one part-time staff member who's already overcommitted. The "participant recruitment" you described? They thought you'd be doing that through your networks. The "community access" that made them such an attractive partner? It's real, but it comes with relationships and protocols you never discussed.

You built the proposal on assumptions about what each partner brings. Those assumptions were reasonable. They were also wrong.

Here's what happened: you approached partnership from a needs-based perspective.

You had gaps in your proposal. You found a partner who could fill them. You described what you needed them to provide without deeply understanding what they actually have.

This is how most partnerships get written. And it's backwards.

The needs-based approach creates several problems. First, it positions partners as gap-fillers rather than genuine collaborators. Second, it makes assumptions without verification. Third, it misses assets that could transform the project if you knew about them.

The alternative is strengths-based partnership design. Instead of asking "what do I need from them," you ask "what do they have that we could build around?"

This sounds like a small shift. It changes everything.