Jacob Top Møller

Free tool

Proof of Value plan checker

A Proof of Value tests whether the product delivers the business outcomes the economic buyer has agreed to. Check one plan before technical validation starts: tick each item once you have checked it. For an item that does not apply, tick it and note why.

Use it for a proof of concept, pilot, trial or evaluation too.

Nothing you write here is sent or saved. Print the page to keep it.

Outcomes

Business outcomes

Ask: Which two to four business outcomes, in the customer's own words, should the proof serve?

Check: An outcome phrased as a product feature, or in the vendor's words, is weak. Send it back.

Who agreed them

Ask: Who said each outcome, and has the economic buyer agreed to it?

Check: An outcome the economic buyer has not agreed is a hypothesis. Do not start technical validation on it.

Capabilities and use cases

Ask: Which minimum capabilities are needed to reach the outcomes, and which use cases demonstrate them?

Check: Starting from the product's capabilities can produce an impressive evaluation that never answers the customer's business question.

Success criteria

Agreed with the judges

Ask: Who will judge the result, and have they agreed the criteria?

Check: A technical win needs success criteria written and agreed before the proof starts.

Compared with what

Ask: What is each result compared with?

Check: Agree the comparison with the people who will judge the result.

Evidence

Ask: What evidence can the proof reasonably produce?

Check: Agree what the proof can show, including any limits, with the people who will judge it.

Dependencies

Ask: Which effects depend on wider implementation or on changes to the customer's process?

Check: Make those dependencies visible before promising to demonstrate the outcome.

Before technical validation

Go or no-go

Ask: Have the account executive and Sales Engineer confirmed the outcomes, the timeline and the next step with the economic buyer?

Check: If nobody can agree what the proof is meant to establish, go back to discovery.

After a successful proof

Ask: What must the customer still do after a successful proof: compare commercial terms, get another approval or plan the implementation?

Check: Agreeing those decisions up front keeps a technical win from being treated as a commitment the customer never made.

Pilot agreement

Check the terms that apply to this proof. If there is no separate pilot agreement, note where the terms are set out or why an item does not apply.

How the period ends

Ask: Does the agreement simply end, or turn into a subscription?

Check: For an automatic transition, check the completed terms for any right to stop it and any notice deadline.

Success, decision and date

Ask: Is it written beside the agreement what result counts as success, who decides, by when, and what follows?

Check: In a signed deal, those details may sit in the completed order form, a schedule or a project plan.

Two dates

Ask: Is the buyer's agreed decision date kept separate from the pilot's end date?

Check: If continued access is needed, letting the pilot end before deciding may leave a gap.

Customer data

Ask: What happens to the customer's data at the end?

Check: The end of access can also affect the evidence available for the buying decision.

Limits on results

Ask: Do the terms limit disclosing results or comparisons?

Check: Read any such clause before the results go into a report that leaves the company.

The buyer's own paper

Ask: On the buyer's own proof of concept paper, which ticked policies bind the proof itself?

Check: Find out which ones apply before the proof is scheduled.

Sources

The items and questions come from the articles on what a Proof of Value needs to prove, proof of concept vs pilot agreements and PoC win rates.

In my Proof of Value training, teams work on their own current or upcoming proofs.

If you think I could help, write to me or give me a call.