Agree on What a Purchase Must Produce Before You Sign

← Back · ACT III · Chapter 16: MAVEN: Controlled Evaluation

Writing down what a purchase has to produce settles a disagreement every deal has anyway, and settles it before anyone signs.

The objection I hear most often to a Request for Value comes from inside the buyer’s own building, usually from someone with a deadline: this will slow us down.

It sounds reasonable. The RFP is already written and the evaluation team is booked. Asking the business owner to stop and write down what the purchase has to produce, in their own terms, feels like one more gate in a process that already has too many.

I understand the instinct, and I think it gets the timing wrong.

The page asks one hard question

Most of the Request for Value is mechanical once the first line exists. The metrics follow from the outcome. The conditions follow from asking what has to be true on your side for the outcome to arrive. Evidence and comparison criteria follow from both.

The first line is the hard one. What does this purchase have to produce, for the business, in words the business would use? Not “implement a modern platform.” Something closer to “the service team closes the same volume of cases next year without adding headcount,” or “we stop writing off the inventory we currently write off every quarter.”

That question is slow to answer for a reason. People who will live with the purchase often disagree about what it is for. Finance wants cost out. Operations mostly wants fewer fire drills, and IT wants one system where it now runs three. Each of them has signed off on the RFP, because the RFP lists features and requirements, and a feature list lets everyone read their own purpose into it.

The disagreement does not go away

Skipping the page moves that disagreement somewhere else.

On the vendor side, we saw where it went. First it surfaced in discovery calls, where three people from the same company described three different problems. Then it was in the proposal, which we wrote to cover all three so nobody felt left out. The expensive place for it was after go-live, because by then the money is spent, the contract is signed, and the argument about what the purchase was for has turned into an argument about whether it worked.

That last argument is the slow one. A steering committee that never agreed on the outcome cannot agree on whether the outcome arrived. Each side brings the measure that suits its original purpose, the vendor brings a dashboard, and the meeting ends with an action item to align on success criteria. Months into the contract, that is the conversation the RFV asked for before the RFP went out.

So the real comparison is between settling that disagreement in a working session before vendors are called, and settling it, or failing to, after the decision cannot be undone.

What the business owner actually writes

The person who will answer for the result writes it down, with whoever else will be measured by it in the room. No consultant or workshop is required.

A useful test for the outcome line is whether someone outside the project could check it a year later without asking what it meant. “Improve efficiency” fails that test. “Cut the time from order to invoice from where it is today, which we will measure before we sign” passes, even with the baseline still to be confirmed. On day one the outcome can still lack a number, as long as it is specific enough that one can be attached later.

When the owner cannot write that sentence, the purchase is not ready to go to market, and it is far better to learn that before vendors are called than after the contract is signed.

What it does to the vendor’s side of the clock

Sellers usually expect the page to slow them down too, and it tends to do the opposite for the ones who can deliver.

A good part of a long sales cycle is the vendor trying to work out what the customer actually wants. Discovery calls, revised proposals, a business case rebuilt for a new stakeholder who joined late. A buyer who arrives with the outcome already written removes much of that. The vendor knows what it is being compared on, and can say early whether it is the right fit. The one that can show results against that kind of outcome at other customers gets to lead with them instead of a generic story.

The vendors who lose time are the ones whose proposals depended on the buyer not having decided, and a buyer should be glad to learn that before signing.

Where the time goes

A Request for Value asks for some hours from the business owner before the RFP goes out. In return, the evaluation compares vendors against one stated purpose instead of several unstated ones, the contract can reference what success means, and the renewal has something to test.

The argument about what the purchase is for will happen either way. The page only decides whether it happens while the answer can still change the decision.

The white paper The Request for Value includes the page itself as a form and is available at valuelattice.com/white-papers/the-request-for-value/.

Keep reading: ACT III · Chapter 16: MAVEN: Controlled Evaluation