A proof-of-concept without pre-written pass thresholds is a guided tour — pleasant, vendor-paced, and decision-free. This guide is the planning method that makes a PoC bite: criteria before access, numbers on every threshold, failure days in scope, and a scorecard the sales cycle cannot bend.
Why PoCs drift and how criteria stop it
Vendor-supported PoCs fail differently from trials: not from neglect but from drift. The vendor's engineers are helpful, scope expands toward what demos well, weeks pass, and the exercise ends with warm feelings and no comparable evidence. The antidote is procedural: success criteria written and agreed — internally and with the vendor — before anyone receives access. Criteria transform the vendor's helpfulness from a steering force into an execution resource: they can help you hit your thresholds, but they can no longer choose what gets measured. A PoC with signed-off criteria is an evaluation; without them it is pre-sales with your calendar.
Write the scorecard before access
The scorecard is one page: six to ten criteria, each with a measurement method and a numeric threshold. Draw them from your requirements page — each workload sentence yields one or two. Good criteria bite: "P95 TTFB under 180 ms from Jakarta and Manila on the top two mobile ASNs, measured by our RUM" bites; "good APAC performance" does not. "Config change from commit to globally live in under 5 minutes via API, demonstrated three times" bites; "strong automation story" does not. Include at least one economic criterion (measured cache behavior priced through your TCO model lands within X of forecast) and one operational one (ticket response at the tier you would buy). Mark each criterion pass/fail — weighting comes later, at the decision meeting, not during the test where it invites rationalization.
Scope: include the failure days
Fix three scope boundaries in the plan. Traffic: which hostnames or percentage go through the candidate, and the promotion path if early results are good — a PoC on synthetic traffic alone proves configuration, not delivery. Time: two to four weeks with named end date; open-ended PoCs are sales instruments. Events: schedule the deliberate failures — origin kill, bad-config rollback, peak-hour purge, support fire drill — as calendar items with the vendor informed they are coming (their behavior when told "we will break things on Thursday" is itself a data point). The failure-day methodology from the trial guide transfers directly; the difference is that here the vendor's engineers are watching, which tests the partnership as well as the platform.
Run it on rails
During execution, three disciplines keep the rails under it. A daily one-line log per criterion — measurements accumulate instead of being reconstructed from memory in week four. A single named owner on your side with authority to keep scope fixed — vendor suggestions get logged as "post-PoC ideas" rather than adopted mid-test, however good they sound, because scope adopted mid-test invalidates comparison with the other candidate. And parallelism where feasible: two candidates PoC'd on split traffic in the same window beat sequential PoCs whose conditions differ — same weeks, same traffic mix, same failure drills, which is the only way "A beat B" means anything. If parallel is impossible, freeze the scorecard between runs absolutely.
The decision meeting
End on the calendar, not on momentum: a decision meeting scheduled at kickoff, held even if results feel obvious. Inputs: the scorecards, pass/fail per criterion with the daily logs as evidence, and the open risks each candidate leaves. The meeting weighs criteria (now, with results visible, weighting is honest rather than rationalizing), decides, and documents — the same one-paragraph defensibility standard as the shortlist. Then the PoC's last artifact: the winning configuration, criteria and measurements become the acceptance baseline for the production migration, so what was proven is what gets deployed. A PoC run this way costs the same weeks as a drifting one; the difference is that it ends with a decision that stays made.