Set the Anchor Before the First Integration

In Never Split the Difference, Chris Voss explains a foundational principle of negotiation: whoever sets the anchor controls the conversation.

The first number thrown out—whether it is a salary, a price, or a deadline—becomes the reference point. Everything that follows is measured against it. Even if the anchor is arbitrary, it shapes perception. It defines what feels reasonable.

The same principle applies to product integrations. And most teams learn it the hard way.

The First Partner Sets the Standard

Your first major integration partner will have opinions. About how they want to connect. About what data they need. About what timeline works for them. About what is "standard" in their world.

If you don't have a documented, defensible answer to "how do we connect?", they will fill the vacuum.

And once that first partner's approach becomes the de facto standard, you are anchored to it. Every future partner integration compares to what the first was like. Every internal conversation references "how we did it with Partner A."

The problem is that Partner A's approach was negotiated under pressure, without precedent, with a team that was still learning. It probably included accommodations that made sense in the moment but created long-term complexity.

Now that is your anchor. And it is pulling you in the wrong direction.

The Power of a Pre-Defined Approach

Voss talks about the importance of going first and setting the anchor before the other party can. In integration work, that means having a "how to connect" document before you have a partner to connect.

This feels counterintuitive. How can you define the process before you have done it? Will you not learn things that change the approach?

Yes. You will. But that is not the point.

The point is to establish a reference. A stake in the ground. A position you can negotiate from rather than a void you are negotiating into.

When you have a documented approach, the conversation changes:

Without an anchor: "How should we connect? What works for you?"

With an anchor: "Here is our standard integration process. Let us walk through it and identify where you need to diverge."

The first conversation is collaborative in a way that sounds nice but costs you control. The second is collaborative in a way that maintains your position while still being flexible.

Divergence Becomes Visible

Here is the real power of setting the anchor: it makes divergence explicit.

When you don't have a standard, every partner request feels like a fresh negotiation. Should we support their authentication method? Should we adjust our data format? Should we accommodate their testing timeline? Each decision is made in isolation, without context.

When you do have a standard, those same requests become deviations. And deviations require justification.

"Our standard is X. You are asking for Y. Help me understand why Y is necessary, and let us discuss the implications."

That is not adversarial. It is clarifying. It forces both sides to articulate the cost of customization. It creates a paper trail of decisions. And it gives you a defensible position when leadership asks why the integration took longer or cost more than expected.

The Anchor Evolves—But It Never Disappears

Your first integration will teach you things. Your "how to connect" document will need updates. Some of what you thought was best practice will turn out to be wrong.

That is fine. The anchor is not meant to be permanent. It is meant to be the starting point.

After each integration, you refine it. What you called "recommendations" become "requirements." What you called "optional" becomes "mandatory." What you learned the hard way becomes a gate that future partners must pass.

But the anchor never disappears. It just gets more accurate.

The teams that struggle are the ones who never set an anchor at all or who let each new partner reset it. They end up with a dozen different integration patterns, a dozen different sets of accommodations, and no coherent story about what "standard" means.

How to Build the Anchor

If you don't have a "how to connect" document yet, start with these questions:

What is the expected integration path? Define the phases: discovery, technical setup, certification, pilot, production. Make the sequence explicit.

What are our requirements vs. recommendations? Be honest about what is negotiable and what is not. If something is truly required, say so. If it is a preference, say that too but explain the tradeoff.

What does the partner need to provide? Authentication credentials, test environments, point of contact, technical documentation. List it. Make it a checklist.

What are the gates? Define what must be true before moving from one phase to the next. No certification until testing is complete. No production until certification passes. No executive involvement until prerequisites are verified.

What is the communication structure? Weekly syncs, shared chat channels, escalation paths. Define it upfront so you are not negotiating it mid-project.

You will not get all of this right the first time. But having a wrong anchor is better than having no anchor. At least you will learn where it needs to move.

The Negotiation Mindset

Voss's book is about high-stakes negotiation: hostages and life-and-death situations. Integration partnerships are not that dramatic.

But the underlying principle is the same: the party that defines the frame controls the outcome.

If you let your first partner define how integrations work, you will spend every subsequent integration re-negotiating from a position of weakness. You will accommodate things you should not. You will customize things that should be standard. You will wonder why every integration feels harder than it should.

If you define the frame first, you have something to fall back on. A reference point. A position.

Not to be rigid. Not to be inflexible. But to be anchored.

Set the anchor before the first integration. Because if you don't, your partner will.