How PartnerLab evaluates an AI partnership.
The framework is designed to make partnership thinking inspectable. It separates documented platform capabilities from hypotheses about product design, commercial alignment and launch strategy.
1. Start with the user job, not the logo
A partnership is only strategically interesting when it removes meaningful friction or creates a new capability. We define the user, the job to be done, the present workflow and the exact moment where an integration changes the outcome.
2. Map the action surface
Read access can create context; write access can create leverage. We identify what an agent could retrieve, propose, create, update or transact—and which actions should remain preview-only or require explicit confirmation.
3. Validate technical feasibility
Public documentation is used to inspect API coverage, OAuth or app authorization, scopes, webhooks/events, rate limits, enterprise controls and the distinction between public interfaces and partner-only access. A compelling product concept can still be a weak near-term partnership if the technical or data-rights surface is immature.
4. Test reciprocal economics
Distribution alone is rarely enough. We ask what each side gains: user engagement, completed transactions, platform retention, developer adoption, enterprise expansion, ecosystem breadth, new revenue or lower support/operating cost. Durable partnerships generally have more than one value pathway.
5. Design trust into the product
Permissions, identity, confirmation, logging, reversibility and disclosure are product requirements—not legal footnotes. Higher-impact actions demand stronger controls and clearer evidence of what actually happened in the partner system.
6. Sequence the launch
PartnerLab favors a design-partner path: start with a narrow workflow, prove reliability, measure user corrections and support burden, then expand scope. The sequencing should create evidence that unlocks the next phase rather than forcing a broad launch before the integration earns trust.
The illustrative opportunity index
| Lens | Question | Illustrative weight |
|---|---|---|
| User value | Does this meaningfully improve an important workflow? | 25% |
| Action surface | Can the integration do useful work, not just retrieve text? | 20% |
| Technical fit | Are auth, APIs, events and permissions viable? | 20% |
| Partner economics | Is the value reciprocal and durable? | 20% |
| Trust + control | Can risk be governed in the product? | 15% |
The resulting number is a shorthand for internal comparison. It is not an external company rating, investment recommendation or forecast. The written reasoning is the primary output.
Editorial standard
We prefer primary technical documentation, clearly label hypothetical analysis, identify material unknowns and avoid implying that a named company endorses or participates in a concept. As the research library grows, each brief will maintain a visible update date and source list.