Foundations
Promise
Promise is the change in the other side's situation that your offer commits to produce or make possible. It defines the future state you are asking them to value.
Promise is a design object, not copy. It is decided before anything is written, and it is one of the few parts of an offer you can strengthen without simply giving away more money.
Capability is not a promise
Most proposals stop several steps short of a promise. The distinctions matter because each level asks the other side to do more of the interpretive work themselves.
Capability
What the thing, resource, service, or right can do or enable.
Feature or term
How that capability, or the exchange itself, is packaged and exposed.
Benefit
Why that packaging might be useful to someone.
Outcome
A result in the other side's world, not in your description of it.
Promise
The proposed, committed change in their state — with scope and conditions attached.
In a licensing or acquisition context the vocabulary shifts — capability becomes an asset or a right, features become terms — but the ladder holds. The party being asked to agree still has to see a change in their own condition.
Promise is a delta
A promise has no value in isolation. Its value comes from the gap between where the other side is now and where your offer proposes to put them. That is why the problem, or the objective, is part of the promise rather than a preamble to it.
Current problem or objective
What is wrong, or what they are trying to achieve.
Causal constraint
What is actually preventing that today.
Mechanism or structure
What in your offer removes or works around that constraint.
Promised future state
The specific condition they end up in, scoped and conditioned.
Treat this as a design sequence, not a formula. It is a way of catching the common failure: a promised future state with no identified constraint standing in its way, and therefore no reason to believe your offer is what changes anything.
The same asset supports different promises
Promise is designed against a particular party in a particular situation. Nothing about the underlying capability has to change for the promise to change completely.
Example — a scheduling and dispatch platform
To a national field-service operator, the promise might be that overtime spend falls measurably within two quarters across the regions that adopt it. To a fast-growing regional firm, the promise is different: that they can triple technician headcount without adding coordinators. Same software. Different constraint, different delta, different promise — and each is worth a different amount.
Example — seeking a licence to proprietary technology
Here you are the one asking, and the promise runs toward the technology owner. The capability is theirs. What you are promising is a change in their situation: recurring revenue from a field they are not serving, commercialisation without spending their own capital, retained rights in the markets they care about, and validation of the technology in a demanding application. If you cannot articulate that future state, you are not making an offer — you are making a request.
Scope the promise
An unscoped promise is either not believed or not survivable. Scope is what makes it both credible and safe to stand behind.
What
Precisely which condition changes.
For whom
Which team, unit, market, situation, or use.
Under what conditions
The assumptions and inputs the promise depends on.
By when
The realistic horizon, not the best case.
To what degree
The magnitude you are willing to be held to.
If it does not occur
What you do about it — where that is appropriate to state.
Promise strength has several dimensions
Strength is not a single quantity, and these do not add up to a number. Which one matters is a property of the other side's situation, not of your offer.
Magnitude
How large the change is.
Speed
How quickly it arrives.
Completeness
How much of the job it actually finishes.
Certainty
How reliably it happens — claim only what you can support.
Durability
Whether it persists or decays.
Breadth
How much of their situation it touches.
Convenience
How little they must rearrange to get it.
Strategic importance
Whether it matters to something they care about at the top.
“A stronger offer starts with a more valuable promise, not more language about the same promise.”
Precision beats vague breadth. A narrow promise that names a specific condition, in a specific situation, on a specific horizon can be worth far more than a grand generic one — because it can be inspected, planned around, and defended internally by whoever has to approve it.
Precision also changes substitutability. A promise built around the particular shape of this party's problem is harder to swap for a competitor's, or for doing nothing. But distinctiveness without relevance is worthless: being the only one promising something nobody needs is not an advantage.
Dependencies
Every promise rests on things that must hold. Naming them is not weakness; it is how you find out whether the promise is realistic and where it will be doubted.
- Behaviour and decisions on the other side
- Data, inputs, or assets they must supply
- Implementation work, and who performs it
- Third parties, integrators, regulators, partners
- Timing and sequence of events
- Market or operating environment holding steady
Dependencies are where promise meets the rest of the structure. Dependencies that sit on the other side become burden. Dependencies they doubt become a credibility problem, whether or not you think the doubt is fair.
Bigger is not automatically better
Promise inflation
Every increase in what you claim raises the burden of belief, and often raises cost, effort, and risk on both sides. A promise that outruns your evidence makes the offer weaker, not stronger — the other side discounts the whole proposal, including the parts that were true.
Bundling
Adding components does not strengthen a promise. Finishing more of the actual job does. If the extra pieces remove work the other side would otherwise have to do themselves, the promise genuinely grows. If they just lengthen a list, it does not.
Promise audit
Short enough to run on a live deal before the next proposal goes out.
- 01State the promise in one sentence, as a change in their condition.
- 02Name the current state it is a delta from.
- 03Identify the constraint that is actually in the way today.
- 04Name the mechanism in your offer that addresses that constraint.
- 05Scope it: what, for whom, under what conditions, by when, to what degree.
- 06List the dependencies, and mark which ones sit on their side.
- 07Ask which strength dimension actually matters most to this party.
- 08Ask whether a narrower, more precise promise would be worth more to them.
- 09Ask what the promise now obliges you to stand behind — and whether you will.
A promise is what the offer will actually stand behind.
If you would not accept a term, a milestone, or a remedy attached to it, you have not made a promise. You have made a description.
Where this sits in the framework
Promise is not being introduced as a seventh dimension. It is an offer-design concept that the current six-dimensional model underrepresents. The six dimensions stay in place provisionally while the architecture is reconciled through use rather than by declaration.
Promise relates closely to Value Creation without being identical to it. Value Creation describes what value the deal can produce. Promise describes the future state the proposed offer actually asks the other side to rely on and pay for. A deal can create real value while promising something too vague to be relied on — and an approval committee cannot fund a vague delta.
Deal Geometry Diagnostic
Is your promise the strongest one your capability supports?
The Deal Geometry Diagnostic reviews a sample of recent transactions and identifies the structural issues slowing your deals down.