ENDE

Harvard method: negotiate on interests, not positions

Interest-based negotiation moves beyond fixed demands. It reveals options that protect what matters to both sides.

  • Separate positions from interests
  • Create options for both sides
  • Decide against shared criteria

Start a reflection about:

Also helps with:Annual planningA reorganization

Interest-based negotiation in 4 steps

Positions state what each side demands. Interests reveal why it matters. Use those interests to find options, then test them against shared criteria.

  1. Separate people from the problem

    Name the conflict without treating the people or teams as the problem.

  2. Clarify interests

    Ask about the goals, needs, and limits behind each demand.

  3. Create options for mutual gain

    Generate options that could serve important interests on both sides.

  4. Agree on criteria

    Test the options against data, standards, or conditions both sides accept.

When this method helps

Use when teams have different priorities and must implement the solution together.

Key benefits

  • Moves the conversation from positions to interests
  • Creates workable options for both sides
  • Tests decisions against shared criteria

Limits and when to pause

Not every conflict has a mutual-gain solution. Protect firm boundaries, test objective criteria, and know your alternative if no agreement is reached.

Interest-based negotiation examples

The four steps stay the same whatever two teams disagree about. What changes is what is at stake: a date, people both teams need, or the way work passes from one team to the other. Each example shows the steps separately and then how you could open the conversation.

A release date against a reliability risk

Keep a promise to a customer without taking on an unstable launch.

Illustrative scenario

Separate people from the problem
The product team promised a large customer the new reporting feature for 1 March. The platform team warns that the reporting queries could overload the shared database. Instead of calling each other blockers, the two leads name the conflict: a promised date against an unresolved reliability risk.
Clarify interests
The product team needs to keep the promise because the customer renews its contract in March. The platform team needs to avoid an unstable launch and more night pages; it already had 23 last quarter.
Create options for mutual gain
They consider a staged rollout: the feature goes live behind a flag for the customer's 40 users first, with close monitoring, and the heaviest exports run at night.
Agree on criteria
Before the rollout grows, they set thresholds for the first week: error rate below 0.5 percent and database load below 70 percent. If either is exceeded, they switch the flag off.
How you could open
We both want the reporting launch to work, and right now we're arguing about a date. Can we treat it as one problem: how do we keep the 1 March promise without putting the shared database at risk? One idea is to launch for the customer's 40 users behind a flag. Could we agree now on the numbers that would make us switch it off?

Two teams, one shared resource

Share people both teams need without a winner and a loser.

Illustrative scenario

Separate people from the problem
The checkout and onboarding teams each ask for two of the three product designers for all of Q3. Instead of arguing about whose project matters more, the two product managers name the problem: three designers, and two projects that each want two.
Clarify interests
Checkout needs final designs before its user tests in week 6. Onboarding needs its research finished before engineering starts in week 8. Neither team needs two designers for all twelve weeks.
Create options for mutual gain
They sketch a split: until week 6, two designers work on checkout and one on onboarding research. From week 7, two move to onboarding and one stays on checkout for changes after the tests.
Agree on criteria
They check the split against both teams' milestones and the design lead's effort estimates. If the user tests move, they review the split in week 5.
How you could open
We both asked for two designers for the whole quarter, and there are three. Can we plan around our dates instead of the headcount? Checkout needs final designs by week 6, and onboarding needs its research done by week 8. What if two designers work on checkout until week 6 and then two move to onboarding?

Escalations between support and engineering

Replace a daily tug of war with a rule both teams can work with.

Illustrative scenario

Separate people from the problem
Support escalates customer bugs to engineering by chat, often several a day. Engineering calls it constant interruption, support calls it stonewalling. The two leads agree to name the actual conflict: stuck customers on one side, planned work that never gets finished on the other.
Clarify interests
Support needs a same-day answer when a customer cannot work; last month that was true for 9 of 60 escalations. Engineering needs uninterrupted time for planned work; last sprint it lost about a third of its time to escalations.
Create options for mutual gain
They sketch two paths. Blocking bugs go straight to one engineer on a weekly rotation, with an answer within four hours. Everything else goes to a triage twice a week, and support sees the status in the ticket.
Agree on criteria
They agree on what counts as blocking: the customer cannot finish a core task and has no workaround. After four weeks, they review response times and how many escalations skipped the triage.
How you could open
We're both frustrated with how escalations work, and I don't think either team is the problem. Your customers need an answer when they're stuck, and we need time for planned work. Last month, 9 of the 60 escalations came from customers who couldn't work at all. Could we handle those cases differently from the rest, and first agree on what counts as blocking?

Each opening names the shared problem before any demand and ends with a question. Keep your criteria ready for when you compare options.

Position or interest?

A position states what a team demands. An interest states why. Positions leave room for yes or no; interests can be met in more than one way, and that is where options come from.

  • Position“We need two designers for the whole quarter.”

    Interest“We need final designs before our user tests in week 6.”

  • Position“We launch on 1 March, no matter what.”

    Interest“We promised 1 March because the customer renews its contract that month.”

  • Position“Every customer bug has to be fixed within 24 hours.”

    Interest“When a customer can't work, we need to give them an answer the same day.”

When you only hear a position, ask what it protects. The first answer is often another position, so ask again.

Template: open your negotiation between teams

Copy the template and replace each bracket with your own case.

We both want [shared goal]. The problem we need to solve together is [conflict, without blame]. What matters to us is [your interest]. As I understand it, you need [their interest]. One option could be [option]. Can we agree to judge it by [criterion both teams accept]?

Check before you say it

  • Separate people from the problem: Does the problem statement work without naming a person or team as the cause?
  • Clarify interests: Did you name the reason behind each demand, including the other team's?
  • Create options for mutual gain: Do you have more than one option, and does each serve something the other team needs?
  • Agree on criteria: Would the other team accept your criterion before knowing which option it favors?

Questions Reflacto asks

Getting to Yes describes four elements: separate the people from the problem, focus on interests, invent options for mutual gain, and use objective criteria. Four questions follow the first three: each team's priorities and constraints, where their goals align or conflict, the conflict framed as a shared problem, and a solution that benefits both. Reflacto added the first question, which lists the teams involved. Objective criteria have no question of their own; they come up in the plan at the end.

Conflict across teams

Find a solution two teams can carry out together despite competing priorities.

  1. 1Which teams are involved in this conflict?Added by Reflacto
  2. 2What are the main priorities and constraints for each team?From Getting to Yes
  3. 3Where do their goals align or conflict?From Getting to Yes
  4. 4How can you frame this as a shared problem to solve?From Getting to Yes
  5. 5What compromise or mutual benefit is possible?From Getting to Yes

After the last question, Reflacto shows a negotiation plan with concrete next steps, including the criteria for judging a solution and each side's alternative if you don't agree.

Questions about using interest-based negotiation

Before the conversation

How do I find the interest behind a position?

Ask why the demand matters and what would go wrong without it.

You could say
“What happens on your side if the launch moves by two weeks?”

The first answer is often another position, so ask again. Deadlines, the numbers a team is measured on and past incidents are common interests. Positions and interests side by side

What is a BATNA and why does it matter?

Your BATNA is your best alternative if no agreement is reached. It shows when walking away is better than accepting the offer.

You could say
“If we can't agree by Friday, it goes to the head of product, and both teams lose a week.”

Define it before negotiating, and think about the other team's alternative too. Between teams in one company, the alternative is often escalation, which neither side controls.

Options and criteria

What's the difference between this and a compromise?

A compromise splits a fixed amount. Interest-based negotiation looks for needs that matter differently to each side, so a trade can serve both better than a split.

You could say
“Checkout doesn't need two designers all quarter, only until week 6.”

You can still split the difference at the end, but try trades first. Example: two teams, one shared resource

What counts as an objective criterion?

A standard both sides accept before they know which option it favors: data, service levels, contract terms or a deadline someone else set.

You could say
“Let's call a bug blocking if the customer can't finish a core task and has no workaround.”

Agree on criteria before you compare options. Otherwise each side picks the measure that favors its own proposal. Example: escalations between support and engineering

When it gets hard

What if the other side won't move from its position?

Ask for the reason behind the demand, then suggest criteria such as data or standards.

You could say
“Help me understand what the 24 hours protect. Is it the contract, or customers who can't work?”

This moves the conversation from pressure to reasons. If they still refuse, compare their offer with your BATNA.

Does it work when one side has far more power?

Only partly. The method cannot create leverage.

It clarifies what you need, what is negotiable and where conceding would hurt most. If the decision belongs to someone above both teams, ask them for it. Limitations

About the method

Is this the same as Getting to Yes?

Yes. It applies the principles Roger Fisher and William Ury presented in Getting to Yes (1981) to conflict between teams in one organization.

In German, the approach is known as the Harvard-Konzept. Reflacto's questions cover interests, the shared problem and options; criteria come up in the plan at the end. Origin and sources

When should I not use it?

When the conflict is between two people rather than two teams' priorities, or when there is nothing left to negotiate.

A personal clash usually needs a mediation conversation first. If someone above you has already decided, prepare an alignment conversation instead. When to use it

Origin and Reflacto's adaptation

Roger Fisher and William Ury presented principled negotiation in Getting to Yes (1981). Bruce Patton, originally credited as editor, is a co-author in current editions. All three belonged to the Harvard Negotiation Project.

Also known as: principled negotiation, the Harvard negotiation method

What Reflacto changed

From the original model
From Getting to Yes: the interests behind each team’s priorities, where the teams’ goals align or conflict, the conflict framed as a shared problem, and options for mutual gain.
Added by Reflacto
Reflacto applies the method to conflict between teams in one organization, starts by listing the teams involved, and ends with a plan that adds objective criteria and each side’s alternative if no agreement is reached.

See every question Reflacto asks

Primary sources and further reading

Editorially reviewed by Daniel Schmeiß

Last substantive review: September 29, 2026

Related reflection methods

Compare another method that approaches a similar situation from a different angle.

Compare all methods