Framework · The workspace
Deal Geometry Map
Map the offer before you negotiate it.
The Map is where a live deal gets designed and redesigned. It answers five questions in order: what is on the table, why might the other side reject it, what can you change, what else would that change, and does the resulting deal still work for you. Everything earlier in the framework exists to fill it in.
The purpose of the Map is not to describe the deal. It is to show you where to move it.
A live deal is too interconnected to reason about one term at a time. Price is discussed in one meeting, the term in another, implementation in a third, and by the time all three are settled the structure makes no sense to anyone. The Map turns a deal from a list of disputed terms into a system you can redesign.
It is not a model of two neutral parties. You are the practitioner, and you have an objective. The other side matters because their acceptance is the constraint standing between you and that objective — which is exactly why you model them carefully.
Ten layers, one workflow
Layers one to four record what is true. Five and six find what is wrong. Seven to ten are the redesign. Read downward: each layer is only useful because of the ones above it.
01
Your objective
What you are actually trying to get
The outcome that makes this transaction worth doing, what must be preserved for it to stay worth doing, and the point at which you stop. Written first, so redesign later cannot quietly erode it.
02
The offer
The proposed exchange as it stands today
Promise, what you receive, what they receive, economics, scope and rights, who does the implementation, sequence and dates, risk allocation, commitment, and any options or governance attached.
03
Credibility and evidence
Why they should believe the promise holds for them
The proof behind the claim, in their circumstances rather than in general. What evidence exists, what is missing, and what would be expensive for you to say if it were not true.
04
Their decision context
The environment the offer has to survive
What they are trying to accomplish, what they will do instead, their reference alternatives, the stakeholders and approval path, budget shape, constraints and preferences, urgency, and how they will compare mechanisms.
05
Stress-test lenses
Value creation, value capture, burden, risk, commitment, timing
Not scores. Six ways of interrogating the structure to expose where it imposes cost, exposure or commitment at a point where it cannot be absorbed.
06
Friction and diagnosis
What is observably not working, and why
Objections, stalls, redlines, failed approvals, silence, requested concessions — each separated into the observation, the hypothesised constraint underneath it, the evidence, and the unknowns.
07
Deal moves
Candidate transformations tied to a diagnosis
Structural changes aimed at a specific hypothesised constraint. Each one written as a move card, not as a vague willingness to be flexible.
08
Propagation
What else changes because of the move
Every candidate traced through the six lenses, credibility, their decision context and approval path, and your own economics, capacity and precedent.
09
Candidate configurations
Whole offers, not isolated terms
One to three coherent redesigns you would genuinely sign, compared qualitatively so the tradeoffs are visible and the choice is deliberate.
10
Learn and update
What their response would tell you
The prediction attached to each configuration, and the discipline of rewriting the map once the offer has been tested against reality.
The Map is never finished
A deal map is not a document you complete and file. It is the state of your current understanding, and every objection, approval, diligence result, pilot outcome, counteroffer, redline and corridor conversation changes it.
If the Map looks the same after three conversations, either the deal is unusually simple or nobody is updating it. The value is in the revisions.
Both sides, without pretending to be neutral
You record both sides of every important variable, and you do it for a reason: that is where asymmetric value and acceptance constraints become visible. Six questions per variable.
- What is this variable worth to you, and what does it cost you to give?
- What is it worth to them, and what would obtaining it elsewhere cost?
- Who actually controls it?
- Who bears the burden and the risk attached to it?
- Who inside their organisation cares about it, and who can veto it?
- How does it compare with their reference alternative on this point?
Variable
Value / cost to you
Value / cost to them
Who controls it
Price and payment shape
To you
Economics, margin, revenue quality, precedent
To them
Budget line, cash timing, procurement benchmark
Control
Shared — you set it, their approvers gate it
Scope and rights
To you
Delivery cost, capacity, what you keep
To them
How much of their problem is actually solved
Control
You, until they redline it
Implementation work
To you
Cost per hour of your delivery capacity
To them
Internal effort they may not have available
Control
Whoever the contract says
Risk allocation
To you
Exposure you can price and absorb
To them
The downside their sponsor is personally carrying
Control
Rarely the party bearing it — check this
Term and exit rights
To you
Forecast certainty, cost of churn
To them
Future choice surrendered before evidence exists
Control
Written now, felt later
Sequence and dates
To you
When work happens, when revenue lands
To them
When value starts, when cash leaves, when approval closes
Control
Partly neither — budgets and calendars
Both sides are recorded, and never averaged. You are not scoring fairness — you are looking for variables that are cheap for you and expensive for them to obtain elsewhere.
The geometry is in the relationships
This is where the name earns itself. The framework's value is not the list of variables — it is the way they are wired to each other. Move one and the others move.
Price ↔ Commitment
A lower price becomes viable when a longer term or a volume minimum arrives with it. Neither term is negotiable in isolation without giving something away.
Credibility ↔ Risk ↔ Commitment
Thin proof makes a large irreversible commitment hard to approve. Strengthen the evidence and the same commitment becomes signable.
Burden ↔ Value
Implementation effort can erase the value of an attractively priced deal. What they net is the promise minus the work of getting it.
Timing ↔ Value Capture
The same nominal economics at different points allocate the financing of the deal to a different party.
Exclusivity ↔ Value Capture ↔ Commitment
Exclusivity can create real value while consuming optionality, which is why it usually belongs attached to minimum performance or economics.
Scope ↔ Burden ↔ Timing
A narrower first phase lowers implementation load and brings proof forward, at the cost of later full capture.
Reference alternative ↔ Differentiation
A structural change can move the deal out of a like-for-like comparison altogether, which no amount of positioning does.
The friction map
Friction is not a list of complaints. Each item is a piece of evidence about where the current structure fails, recorded in a way that separates what you saw from what you inferred. Eight fields per item, and it feeds straight into a move card.
Observed signal
What was said or done, in their words, not your interpretation.
Source
Which stakeholder or function it came from.
Named variable
The term they pointed at.
Hypothesised constraint
What underneath it plausibly makes yes hard.
Evidence
What supports the hypothesis.
Unknowns
What you are still guessing.
Consequence if unresolved
Delay, reduced scope, lost deal, worse economics.
Candidate moves
Which structural changes could relieve it.
Keeping observation and hypothesis in separate fields is what stops a guess hardening into a fact over the course of a deal cycle.
Worked example
A $300K platform deal that is "twenty percent too expensive"
Current offer: $300K per year, three-year term, annual prepayment, enterprise-wide rollout across four business units. The response from procurement: twenty percent off, or no deal.
Layer 1 · Your objective and boundary
Acceptable economics and a referenceable enterprise deployment in this segment, without taking on a bespoke implementation you will still be maintaining in two years. Below your floor, or with a discount that resets the renewal base, this deal stops being worth winning.
Layers 2–3 · Offer, promise, credibility
The promise is a faster close and the removal of manual reporting work across four units. Your evidence is strong in one adjacent segment and thin in theirs, and you have no case study for a four-unit rollout on their data stack. That gap is doing more damage than the price.
Layer 4 · Their decision context
Sponsor
Owns a reporting programme that has to show progress within two quarters. Wants this to happen.
Finance
$400K available in the current fiscal year. Next year's line is planned but not committed.
IT
Burned by a failed rollout eighteen months ago. Focused on deployment risk, not price.
Procurement
Holds a competitor quote roughly twenty percent below yours and treats the two as comparable.
Reference alternative
Do nothing for another year, or run the cheaper competitor in one business unit.
Layers 5–6 · Friction and diagnosis
"Too expensive — we need twenty percent off." (Procurement)
Hypothesis: A benchmark problem: two offers are being treated as like-for-like when the scope differs.
Unknown: Whether the competitor quote covers migration and the four units at all.
Finance keeps returning to the current-year number, not the total.
Hypothesis: A budget-shape problem rather than a price problem.
Unknown: Whether next year's line survives a change of sponsor.
IT has added three security and rollback questions to every call.
Hypothesis: Implementation uncertainty, and personal exposure from the last failure.
Unknown: Whether IT can veto or only delay.
Read together, this is not one price problem. It is three problems — budget shape, implementation uncertainty, and a benchmark comparison — that happen to arrive wearing the same sentence. A discount pays for all three and solves at most one.
Layers 7–9 · Candidate configurations
A · Straight twenty percent discount
$240K per year, three-year term, scope and rollout unchanged.
Solves the diagnosis?
Only the benchmark, and only by conceding it. Leaves implementation fear untouched.
Your economics
$180K of contract value gone, and a reference price set for renewal and for other accounts.
Burden and risk
Unchanged. Four units still deploy in six months against a nervous IT function.
Precedent
The worst feature of this option. You have taught procurement what pressure produces.
B · Paid pilot with pre-priced expansion
$75K ninety-day pilot in one unit against written success criteria, then $300K per year for the remaining term at fixed economics.
Solves the diagnosis?
Directly addresses implementation uncertainty and fits the current-year budget. Does not answer procurement's benchmark.
Your economics
Full price preserved; recognition pushed out a quarter.
Burden and risk
Your burden rises — criteria, scoping, a second approval cycle. Their risk falls sharply.
Approval path
A $75K pilot may clear a delegated authority that $300K cannot, changing who has to say yes.
C · Ramped economics with managed implementation
$240K / $325K / $380K across three years, standard configuration only, implementation delivered by your team.
Solves the diagnosis?
Hits budget shape and implementation fear together, and changes what is being compared.
Your economics
Total contract value roughly preserved; cash arrives later; delivery cost rises.
Burden and risk
You take on the work — cheaper for you than for them, but it consumes delivery capacity.
Comparison
Procurement's quote no longer covers the same thing, which is a fact-based answer to the benchmark rather than an argument.
Layer 10 · Predict, offer, update
B and C look stronger than A, but which one is right depends on evidence you do not yet have. So write the prediction down. If implementation fear is the binding constraint, B will be accepted quickly and the pilot criteria will be negotiated hard. If budget shape is binding, C will move and B will stall on the pilot fee. If procurement simply refuses to compare anything other than headline price, both stall — and you have learned that the real decision maker is not the sponsor.
Whatever comes back, the Map is rewritten before the next offer is made.
A different transaction entirely
You want to buy a technology outright. The owner refuses to sell, and more cash has not moved them. Mapping their decision context shows why: what they are protecting is future upside and control over how the technology develops.
The Map points at the mechanism, not the number. Purchase becomes a field-limited exclusive licence: upfront payment, royalty on commercialised revenue, exclusivity confined to your fields of use, commercialisation milestones, reversion if you miss them. Propagation runs through commitment, risk, timing and credibility on both sides — and the deal closes on a question that no amount of extra cash could have answered.
The Map is not a sales artefact. It applies wherever an exchange has to be designed before it can be agreed.
Boundaries on the Map
Redesign without a recorded boundary becomes concession drift with better vocabulary. Your limits belong on the Map, visible, next to everything you might trade away.
Must-have outcomes
Acceptable economics and a referenceable enterprise deployment.
Cheap to trade
Payment timing, phasing, standard configuration work, reporting and access.
Expensive to trade
Unit price, bespoke engineering, uncapped liability, exclusivity without minimums.
Capacity limits
One managed implementation of this size per quarter. The second one costs a different deal.
Precedent limits
No discount that resets the renewal base or that procurement can carry into other accounts.
No deal exists when
The economics fall below your floor, IT's veto is absolute, or what they need is something you do not do.
Principle
The Map should make it easier to redesign a deal — and easier to recognise when there is no deal worth redesigning.
Running the Map on a live deal
Thirteen steps. The order is the method: diagnosis before moves, propagation before acceptance testing, prediction before the offer goes out. Most deals are negotiated in roughly the reverse order.
1 · State your objective and boundary
Before anything else, so the rest of the map cannot talk you past it.
2 · Write the current offer as an exchange
What each side gives and gets, in terms, not adjectives.
3 · State the promise and the evidence
And be explicit about which proof you do not yet have.
4 · Map their decision context
Objective, alternatives, stakeholders, approval path, budget shape, timing.
5 · Run the six lenses and mark friction
Where does this structure ask too much, too early, from the wrong party?
6 · Separate observation from hypothesis
The single most valuable discipline on the map.
7 · Generate moves tied to causal hypotheses
Not a menu of flexibility. Specific changes aimed at a specific constraint.
8 · Trace propagation
Every candidate, through every lens and through their approval path.
9 · Build one to three coherent configurations
Whole offers you would sign, not variations on the discount.
10 · Choose the one worth offering
On tradeoffs you can see, not on which feels safest to send.
11 · Predict the response
Write down what would confirm the diagnosis and what would refute it.
12 · Offer, learn, update the map
Their reaction is the highest-quality information in the process.
13 · Repeat, or stop
Iteration is the method. Endless iteration is a symptom.
Before you split it, check whether there is more of it
When disagreement narrows to a single number, it is worth one more pass: is there a structural change that creates more total value, or that puts a burden, a risk or a commitment where it costs less? Often there is, and the argument dissolves. Sometimes there is not, and the remaining gap is genuinely distributive — in which case say so and deal with it directly.
This is a design objective running under the Map, not a promise that every deal can be made better for everybody, and not a claim that fairness is the goal. The longer treatment is in Pareto Efficiency.
The Map as a set of objects
Written out this way, the Map is not really a document. It is a small set of records that reference each other — which is what makes it repeatable across deals, teams and eventually software.
Objective and boundary
Your outcome, must-haves, cheap trades, expensive trades, walk-away conditions.
Offer snapshot
A versioned record of the exchange currently on the table.
Decision context record
Their objective, alternatives, stakeholders, approval path, constraints.
Friction item
Signal, source, variable, hypothesis, evidence, unknowns, consequence.
Deal move card
Constraint, structural change, propagation, cost to you, return, disconfirming response.
Candidate configuration
A coherent offer assembled from one or more moves.
Learning history
What was offered, what came back, and how the diagnosis changed.
The system, stated plainly
Everything in the framework, in one place.
Deal Design
The practice.
Offer
The design object.
Promise
The future state proposed.
Credibility
Whether they believe it will hold.
Six lenses
The structural stress test.
Decision Context
The acceptance environment.
Friction
Observed evidence of mismatch.
Deal Moves
The transformations available.
The Map
The workspace integrating all of it.
The Deal
The offer ultimately accepted.
This is an operating architecture, not a finished ontology. It is held to the standard that matters for working tools: it should help you design a better offer than you would have designed without it, and tell you when to stop.
Where to go from here
The Map is the end of the sequence and the start of the work.