Deal design lens
Burden
Burden is everything the parties must do, change, coordinate, learn, implement, administer, maintain, or give up to make the exchange work and realise its intended value — apart from the explicit economic transfer examined under Value Capture.
The useful question is not how much burden exists. It is which burden is making the offer hard to accept or hard to succeed, and whether that burden can be removed, reduced, sequenced, standardised, or moved to the party who can bear it more cheaply without wrecking your own economics.
Price is only one thing the other side pays.
Nobody evaluates only what they receive. They evaluate what they must go through to get it: the months of work, the people pulled off other priorities, the approvals, the retraining, the disruption to something that currently functions.
This is the broadened descendant of what Offer Physics called Toll — what a customer had to pay in effort, time, attention, expertise, and change on top of the price. In complex transactions the insight has to run both ways, because both sides can incur substantial non-price cost, and a deal can die from either side's share of it.
Principle
A valuable offer can still fail because the path to the value is too expensive.
What counts as burden.
Not exhaustive, and not mutually exclusive. The list is a prompt for finding the work hiding behind a term, not a taxonomy to file things into.
Where Burden sits between the other lenses.
Burden and Value Capture
Value Capture covers explicit transfers — economics, rights, obligations, and what each side retains. Burden covers the non-price work and disruption required to make the transaction function. They overlap constantly: free implementation is a Value Capture cost for you and a Burden reduction for them. Do not force a term into one box; read it through both.
Burden and Risk
Burden is what must be done even if everything goes to plan. Risk is what might go wrong and who bears the consequence. A six-month migration is burden. The possibility that it takes eighteen months, or fails, is risk. They interact, and they should still be examined separately, because the design moves differ.
Burden and Credibility
The other side may believe your technology works and still doubt the Promise will hold for them, because they know their own team will not do the implementation work. Belief is assessed in their circumstances, not in the abstract. Removing execution burden can raise Credibility without the two becoming the same concept.
Burden and Timing
A burden can be acceptable in total and impossible in the proposed window. Implementation during year-end close, migration during peak season, diligence during a financing round. Sequencing frequently solves a burden problem without changing the amount of work at all.
Burden and Commitment
Migration, training, process redesign, and custom integration create lock-in even where the contract does not. Incurred burden is not formal Commitment, but it has similar effects on future choice — which is worth being honest about when you are on the receiving end of it.
Burden is party-relative.
The same task can cost one party a fraction of what it costs the other, because of expertise, tooling, information, scale, existing process, relationships, or control. That asymmetry is one of the largest sources of design opportunity in any transaction.
If you can automate a migration for roughly $10K of effort that would cost them $60K of internal labour, performing it yourself creates value rather than merely moving cost. That created value still has to be captured deliberately — through price, scope, commitment, or standardisation — or it quietly becomes an unpaid service.
Principle
Put necessary work where it is cheapest to perform, not automatically where convention puts it.
With one qualification: the cheapest performer is not always the right bearer. If moving the work breaks accountability, removes the control someone needs, strips out the participation that adoption depends on, or leaves you carrying cost you cannot price, the efficient allocation is the wrong one.
Reducing burden is not the same as shifting it.
Both are legitimate. They have different second-order effects, and confusing them is how a generous-looking concession turns into an unfunded delivery obligation.
Remove or standardise
Automation, prebuilt integrations, default configurations, fewer approval gates, narrower initial scope, fewer dependencies. Nobody bears this work because it stops existing.
Shift to the cheaper bearer
Vendor-managed implementation, migration performed by the side that has done it fifty times, one party running diligence or filings, licensor-led tech transfer. The work remains; its cost falls.
Sequence it
Phased rollout, one division first, milestone-gated expansion, transition services. Same total effort, spread so the organisation can actually absorb it.
Shifting does not make burden disappear. It changes who bears it, and it almost always changes Value Capture — your margin, your capacity, your precedent for the next deal. Trace that consequence before you offer the move, not after.
The other side is rarely a single mind.
The person who approves the spend is often not the person who absorbs the work. The people who absorb the work frequently have influence, veto, or the ability to let a project quietly starve. A deal can look attractive at executive level and fail because security, IT, finance, legal, operations, or end users are handed the cost.
Each requirement can be modest alone and unbearable together. Distribution matters as much as total. This is why burden belongs in your reading of their Decision Context rather than in a delivery plan written after signature.
Hidden burden explains a familiar set of symptoms: deals that stall with no stated objection, weak adoption after signature, margin that erodes during delivery, and dissatisfaction on transactions where both the price and the promised value looked good.
Burden-oriented design moves.
None of these is right by default. Each works for a specific reason, and each has a cost you should be able to name before you put it on the table.
Vendor-managed implementation
Works when you perform the task repeatedly and they perform it once. Your marginal cost is small; their internal cost is large and comes out of scarce capacity.
Phased rollout
One division, one workflow, one region first. Reduces the coordination load at any single moment and produces evidence before the harder phases begin.
Standardised configuration
Removes decisions rather than moving them. Every configuration choice you offer is meeting time, internal debate, and eventual maintenance for them.
Prebuilt integration
Turns bespoke engineering into installation. The cost is yours to build once, and it converts a blocking dependency into a scheduled task.
Migration and data assistance
Data cleanup is usually the least glamorous and most schedule-destroying item. Taking it on removes the step most likely to stall the deal after signature.
Named project manager
Coordination is real work. Supplying the coordinator removes an unbudgeted internal role that nobody on their side wants to volunteer for.
Reusable diligence and legal package
Pre-answered security questionnaires, pre-approved positions, standard terms. This attacks the burden that sits with the stakeholders who can veto but cannot approve.
Explicit, minimised dependencies
State exactly what you need from them and nothing more. Unnamed obligations get discovered late and are the most expensive kind.
Note also that zero burden is not the objective. Some participation from the other side is what produces the outcome; strip it all out and you get weak ownership, poor adoption, and a promise that never materialises. The aim is purposeful burden, cheaply borne.
Example · Enterprise software
They like the value and the price. Nothing moves.
The economics are agreed in principle. Deployment, however, requires five departments, a data cleanup nobody has budgeted, two integrations, and training across several hundred users. The obstacle is not price, and a discount does not touch it.
Redesign the deployment instead. Start with one division rather than the enterprise. Run the migration yourself with your own tooling. Use a standardised integration rather than a bespoke one. Name their dependencies explicitly and keep them short. Put a proof milestone before expansion.
Burden
Falls sharply at the point where it was blocking — the first six months.
Credibility
Rises, because the first phase is small enough that they can picture their own team completing it.
Timing
Value arrives earlier for one division instead of later for all of them.
Commitment
Smaller and later, which is usually why this version gets signed and the other does not.
Value Capture
You carry migration cost and a smaller year-one contract, against a materially higher chance of any contract and a defined expansion path.
Example · Technology licence
Willing in principle, unable in practice.
You want to acquire or license technology, and the owner is broadly willing. But the transfer requires documentation that does not exist, know-how held in two engineers' heads, internal approvals, and months of transition support from a team already fully committed. A higher purchase price does not create the engineering hours.
Design around the burden. Stage the transfer against defined milestones. Pay separately for transition services so the support is funded rather than donated. Cap support hours so the obligation is bounded and knowable. Make documentation a deliverable with its own milestone. Name the specific engineers and the time expected of them. Take a field-limited initial licence so the first transfer is narrow, with expansion once the process has proven itself.
Nothing here changes what the technology is worth. It changes whether the organisation holding it can say yes — which was the actual constraint.
Architectural note
Burden earns its place as a stress-test lens, not as a claim to be a fundamental dimension of a deal.
It is the broadened descendant of Offer Physics' Toll, and its practical job is to expose the non-price cost of saying yes and of making the deal succeed. It stays analytically visible because folding it into a single net-value figure hides exactly the design moves that are available.
Burden audit
Run this against a live offer.
- 01What must the other side actually do before they receive meaningful value?
- 02Who inside their organisation must do it?
- 03What must you do to make the deal work?
- 04Which tasks are expensive because they sit with the wrong party?
- 05Which burdens can be eliminated or standardised rather than shifted?
- 06Which can be shifted to you cheaply relative to how much they matter to them?
- 07What does shifting them cost you in economics, capacity, risk, or precedent?
- 08Are hidden stakeholder burdens blocking acceptance?
- 09Is the burden itself making the Promise less credible?
- 10Could sequencing make the same burden tolerable?
Next
You have decided who does the work. One question remains: what if it does not go to plan?
Burden assumes the plan holds. Risk asks what happens when it does not, who carries the consequence, and which downside is the one actually blocking acceptance. You can also work a whole transaction end to end with the Deal Geometry Map.