You will not write the code. You will write the document that decides whether the code is possible, and whether it is worth it. That document is the job.
Four questions the scope must answer
- Whose objects. Contacts in their CRM, SKUs in their catalog, assets in their DAM. Name the nouns.
- Which way the data moves. One way, two way, or on a trigger. Most bugs are unanswered ownership.
- How a human connects the accounts. OAuth, API key, install from a marketplace. If a customer cannot finish setup without an email to support, the partnership will not adopt.
- What done means. Latency, what happens when a record is deleted, who sees the error.
If an engineer who was not on the call cannot build from those four, you are not done scoping.
User stories are from the customer
“As a merchandiser, when I approve an asset, it is in the storefront without a manual export.” Not “as a partner manager, we integrate.”
Write stories for both products. Their user has a job. Your user has a job. The integration is the bridge, not the hero.
You are allowed to say “this is an iPaaS, not a native app”
Native marketplace apps, direct APIs, and iPaaS connectors are different costs. Pick on purpose. A Zapier of the workflow can validate demand before you spend a quarter on a certified app. Do not pretend they are the same thing in a QBR.
Launch is part of the scope
A shipped connector with no listing, no help article, and no seller one-pager is a tree falling in a forest. Put those on the same checklist as “auth works.”