# Getting to Yes: the negotiation book that teaches FDEs to ask "why" before agreeing scope or accepting an offer

> First published in 1981 and updated by Penguin in 2011, the book by Fisher, Ury and Patton helps engineers stop haggling with customers over features and start negotiating over the real problem.

Original: https://fdetimes.net/en/books-courses/getting-to-yes-negotiation-for-fdes/

A customer says: "We need this dashboard in two weeks." An inexperienced FDE argues about the two weeks. An FDE who has read *Getting to Yes* asks why it has to be two weeks, and the answer often changes the whole project.

The book by Roger Fisher, William L. Ury and Bruce Patton was not written for engineers. But FDE work is constant negotiation: over scope, deadlines, the definition of "done" and, before any of that, your own offer.

## An old book that is still in print

The first edition appeared in 1981 from Houghton Mifflin, with only Fisher and Ury named as authors. Patton joined for later editions, including the 1991 edition and the 2011 edition published by Penguin. The one to look for is the updated Penguin Books edition released on 3 May 2011, ISBN 9780143118756, 240 pages long.

The publisher presents it as a step-by-step method of negotiation that works in any situation to reach agreements that satisfy both sides. The blurb sounds grand, but the core of the book is compact: the three ideas below are enough to change how you work next week.

## Idea one: don't bargain over positions

The opening chapter, "Don't Bargain Over Positions", argues that positional bargaining produces unwise and inefficient outcomes. When each side holds on to a number, the conversation becomes a tug of war: whoever concedes less wins, and nobody touches the real problem.

Picture the tug of war over those two weeks. You propose four weeks, the customer pushes for three, and you settle on three and a half. Nobody asks what the dashboard is for, so there is a good chance you deliver, on time, something nobody opens. That is exactly the "unwise outcome" the book warns about.

## Idea two: interests sit beneath the request

The book's central line draws a sharp distinction: your position is something you have decided upon; your interests are what caused you to so decide.

Focusing on interests rather than positions is one of the four principles of what the authors call principled negotiation. The Program on Negotiation at Harvard adds that interests are the needs, motives and concerns that lie beneath surface demands.

Back to the example. You ask why two weeks, and suppose the customer replies: the director needs a churn figure for a board meeting. The interest is a trustworthy number, not a full dashboard. A clean query plus one chart could be done in three days, with the full dashboard moved to a later phase.

**Key point:** Customers state positions; your job is to find the reason they chose them.

PostHog's FDE handbook says the same thing in engineering terms: the strongest move is often to fix the customer's mental model, not to build exactly what they asked for. You can only fix that model once you understand the interest behind it.

## Idea three: know your alternative before you sit down

The book introduces BATNA, the best alternative to a negotiated agreement. The logic is simple: you negotiate to produce something better than what you could get without negotiating. So any offer worse than your alternative should be rejected.

For an FDE offer, this means knowing exactly what you already have: your current job, another offer, or the chance to stay with your old team in a role closer to customers.

Consider a case. You are a backend engineer at a stable company and receive an FDE offer that requires you to be on the customer's site for most of the month. Your BATNA is staying in your current job, which is fine but keeps you away from customers.

The position that comes out most easily is "I don't want to travel a lot". When you write down the real interests, you may find two: you need a few fixed days at home each week, and after a while you want to carry lessons from customers back into the product.

Those two interests open up something to trade; "no travel" only opens a tug of war.

So you might accept the on-site schedule as described but fix your remote days, and ask for a clear path into the product team. If the company cannot meet either and the final offer is still worse than your current job, your BATNA gives you a clear reason to decline without guilt.

On project scope, an FDE's BATNA is usually to decline vague work. PostHog requires every engagement to have a measurable outcome, a rough timeline and a shared definition of "done" before implementation starts.

It also advises keeping scope small, because expanding a tight scope is cheaper than unwinding a loose one, and sending a short brief for the customer to confirm before committing.

## What does misapplying it look like?

The first mistake is guessing the customer's interests for them. You conclude "they probably just need the churn number" and cut scope without checking. An interest the customer has not confirmed is still only your hypothesis, and it easily turns into a new position, this time yours.

The second mistake is asking "why" like an interrogation. The question should invite the customer to talk about their pressures, along the lines of "where will this number be used?", not force them to defend their request.

The third mistake is understanding the interests and then taking on more work. Knowing what worries the customer does not mean solving every worry in one engagement. PostHog's advice on small scope is the brake for this. The last mistake is going into an offer negotiation without writing down your BATNA, then conceding step by step simply to avoid giving offence.

## Who should read it, and in what order

If you are an engineer with two to eight years of experience about to move into an FDE role, or you have just taken on your first project, read this before any sales book. Start with "Don't Bargain Over Positions" to see the trap, then the section on interests, then the section on BATNA. At 240 pages, it is a weekend's reading.

But don't read it just to underline. After each part, open a real customer request and rewrite it in two columns: position and interests. You will find that most scope disputes disappear once the second column is filled in correctly.

For your career, let this skill show in your CV and interviews. Instead of writing "worked with customers", write one specific sentence: narrowed an initial request to a smaller scope that still met the need, with a measurable result.

When reading FDE job descriptions, look for lines about agreeing scope or aligning expectations with customers, and have exactly one such story ready to tell when asked.

More than forty years after the first printing, the question Fisher and Ury posed is still the most valuable one in a first customer meeting: "Why?"

**Try this week:**

- Take your most recent customer request, write one line for the position and three lines for the interests that might lie behind it, then ask the customer to check them.
- Send the customer a half-page brief with a measurable outcome, a timeline and a definition of 'done' before starting work.
- If you are looking for an FDE job, write down your best alternative before your next offer conversation.

## Sources

- [Getting to Yes by Roger Fisher, William L. Ury, Bruce Patton: 9780143118756](https://www.penguinrandomhouse.com/books/324551/getting-to-yes-by-roger-fisher-and-william-ury/)

- [Getting to Yes - Wikipedia](https://en.wikipedia.org/wiki/Getting_to_Yes)

- [Summary of "Getting to Yes: Negotiating Agreement Without Giving In"](https://www.beyondintractability.org/bksum/fisher-getting)

- [Principled Negotiation: Focus on Interests to Create Value](https://www.pon.harvard.edu/daily/negotiation-skills-daily/principled-negotiation)

- [How forward deployed engineers work - PostHog Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work)
