How to Communicate a Partner Dispute

How to Communicate a Partner Dispute Without Making It Worse

Communicate a partner dispute by leading with the shared customer's operational reality, separating confirmed facts from each party's position and unresolved allegations, acknowledging relevant company history, explaining current action, and giving a specific next update point. Legal, privacy, security, and confidential material should be reviewed before the statement leaves the company.

The audience should not have to adjudicate the dispute to know whether the product will still work.

Start with the shared customer

State which connection, feature, account, data flow, purchase, or service is affected. Explain what works now, what may change, whether the customer must act, and which support path exists.

If the impact is unknown, say what is being tested and when the next update will arrive. Do not convert uncertainty into reassurance that cannot be supported.

flowchart TD
    A["Partner dispute affects shared customers"] --> B["Confirm operational impact"]
    B --> C["Classify facts, positions, allegations, and unknowns"]
    C --> D["Review contradictions and audience memory"]
    D --> E["Legal, privacy, security, and executive review"]
    E --> F["Publish customer-first statement"]
    F --> G["Listen, correct, and update at promised time"]

Use a claim taxonomy

This structure lets a company advocate without presenting advocacy as neutral fact.

The Public Relations Society of America's Code of Ethics emphasizes accuracy, truth, independent counsel, fairness, disclosure, and prompt correction. Those principles are especially valuable when the organization benefits from one interpretation of a moving dispute.

Run the contradiction review

Before publishing, search the company's terms, policies, support pages, developer notices, executive statements, enforcement history, and recent incidents for the same principle.

If the statement says users own their data, identify what that means for access, export, API use, attribution, deletion, and downstream applications. If the company objects to a partner's branding rule, compare the company's own branding requirements. If it criticizes short notice, confirm its own notice history.

A contradiction does not always invalidate the current position. Different scope, placement, use, agreement, user choice, or technical burden may explain it. The statement should explain the distinction rather than pretending the comparison will not occur.

What E086 demonstrated

Strava's original Reddit statement, "Setting the record straight about Garmin," argued that Garmin's attribution requirements harmed user experience and conflicted with user control of activity data.

Replies quickly pointed to Strava's own API and branding restrictions. The post therefore moved the discussion away from customer continuity and toward consistency and leverage.

The thread does not prove that every user rejected Strava's position. It shows that the most visible audience had relevant memory and was prepared to test the argument against it.

Garmin's official API Brand Guidelines were available for readers to inspect. Strava's current API agreement and developer guidelines were also available. A public claim about data and branding was always going to be compared with those records.

Protect the live matter

Do not disclose privileged advice, confidential negotiations, personal data, security details, nonpublic contract terms, or records subject to preservation obligations.

Coordinate the statement with qualified counsel who understands the matter and jurisdiction. The communication guide cannot determine what a party may say during litigation, a regulatory process, or a confidential negotiation.

The public docket in Strava, Inc. v. Garmin Ltd. later recorded a voluntary dismissal without prejudice. That does not authorize a company or publisher to invent a private explanation.

Give the statement a useful architecture

Use plain language. Link to the source policy or filing. Acknowledge uncertainty. Keep the customer's required action near the top.

Listen without treating comments as a referendum

Monitor questions, failure reports, confusion, and contradictions. Code the themes and update the frequently asked questions. Correct errors promptly.

Comments are valuable qualitative evidence. They are not automatically representative of the full customer base. Pair them with support volume, product telemetry, churn reasons, interviews, and direct partner feedback.

Do not argue with individual customers from the corporate account while facts are moving. Do not astroturf support or encourage employees to conceal their affiliation.

Close the communication loop

Publish the promised update even if the only new fact is that discussions continue and service remains unchanged. Silence after a dramatic statement makes the audience rely on speculation.

When the matter resolves, explain the operational outcome, user impact, data treatment, and effective date. Separate any confidential boundary from the facts that customers need.

[[What Happens When an API Policy Changes Under Your Product]] provides the internal operational sequence. [[User Data Portability and Platform Attribution Are Different Questions]] helps prevent a public statement from collapsing source, movement, and rights into one slogan.

This page provides general communications guidance, not legal advice. It reflects sources reviewed on July 27, 2026. AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.