How do you scope a proof of concept so that it closes the deal?

A POC is a decision instrument, not a trial

The purpose of a proof of concept is to remove a specific reason not to buy. Confusing it with a trial, a pilot or a free head start on delivery is the origin of nearly every POC that consumes six weeks and closes nothing. If you cannot name the sentence a stakeholder is currently saying that stops the deal — "we don't believe it will hold our event volume" — then there is nothing to prove and you are being asked for free work.

So scoping works backwards from the decision: who decides, what they need to see to decide yes, and what happens the day after the POC passes. If the last one is vague, the POC is not connected to a purchase and technical success will not fix that.

Written exit criteria, signed before anything is built

Every criterion must be a testable statement with a pass threshold and a named owner, agreed in writing by the person who will make the buying recommendation — not the enthusiastic engineer who invited you in, and not a procurement contact relaying messages. The signatory matters more than the criteria, because an unsigned criteria document is a to-do list that grows.

The wording discipline is that each line has to be falsifiable by someone who is not in the room. "Ingests our telemetry at production rate" is not falsifiable; "sustains 20,000 events per second for 30 minutes with p99 write latency under 200 ms, on the sample file the customer provides" is. A criterion nobody can fail is a criterion nobody will credit you for passing.

Ask two more things of the document. It must state what is explicitly out of scope, because that list is what you point at in week three when someone asks for single sign-on you never agreed to. And it must say what happens if all criteria pass — usually a commitment to move to commercial terms. That sentence converts the POC from an experiment into a step in a process.

Two or three doubts, not a miniature implementation

The instinct, especially from engineers, is to build something impressive. Resist it. A POC should test only the claims genuinely in doubt, and most claims in most deals are not in doubt at all — you have other customers running the same integration and a reference architecture to show for it. Those belong in the proposal, with evidence, not in a build.

So sort each item on the customer's wish list into "we can already prove this with a reference, a document or a fifteen-minute demo" versus "neither of us honestly knows how this behaves in your environment". The second pile should hold two or three items. If it holds nine, you have a discovery gap rather than a POC scope.

Cut hard for a second reason too: every extra criterion adds a way to fail. Eleven criteria of which nine pass gets summarised to the steering group as "mostly worked", where three of three is a result someone can act on.

The time box

Put a hard calendar limit on it — commonly two to four weeks of elapsed time — with a readout meeting in the diary before day one and an agreement that unmet criteria at the end date are reported as unmet rather than extended. Without that date the POC drifts, your engineer stays allocated, the sponsor's attention moves on, and nobody decides anything.

The time box also protects the customer from themselves, because an open-ended evaluation lets an internal sceptic keep adding tests and the sponsor rarely has the standing to stop it. A published end date gives both of you a reason to say no.

What you need from them

A POC that depends only on your effort is a demo. The customer commitments are the real qualification signal, so ask for them in writing, each with a date and an owner's name: a named technical owner with allocated hours per week, representative data by a specific date, a sandbox with credentials issued, firewall changes raised as tickets before kickoff, and any security review completed rather than pending.

If they agree and deliver, the evaluation is real and you will hit your dates. If they cannot free up an engineer for four hours a week or get you data, that is information worth more than the POC: this is not a funded priority, and you learned it before spending your delivery capacity. Slippage on their side pauses your clock openly rather than being absorbed into your timeline.

An exit-criteria sheet you could actually sign

#	Criterion	Pass threshold	Owner
1	Ingest customer telemetry from the existing Kafka cluster	20,000 events/sec sustained for 30 min, p99 write latency < 200 ms	Vendor SA / customer platform lead
2	Authenticate against corporate Entra ID with existing group mappings	Three named test users sign in and land in the correct roles, no directory changes	Customer identity team
3	Reproduce the month-end reconciliation report from the supplied extract	Totals match the customer's current report to the penny	Customer finance analyst

Out of scope: high availability and failover, custom report authoring, historical backfill beyond the supplied extract, integration with the CRM.

Duration: 15 working days, ending 20 August, readout 21 August. If all three criteria pass, the customer proceeds to commercial discussion for a phase-one deployment.

That fits on one page, which is the point. A nine-page scope has stopped being a scope and become a small statement of work.

Refusing an unscoped POC

You will be asked to "just get something running so we can have a look". Say no in a way that gives them something smaller immediately: "I would rather not start a build we cannot judge. Give me an hour with your platform lead to write down the three things you need to see — if we have already proven them elsewhere I will bring you the evidence this week and save us both a month."

Two forms of pressure make this hard: an account executive who wants activity on the deal, and a prospect implying a competitor has already agreed. The argument that works against both is consequence rather than policy — an unscoped POC has no definition of done, so it either runs until someone loses patience or gets judged against criteria invented afterwards. If you cannot get criteria and the deal is worth chasing anyway, the fallback is a paid discovery engagement, not free open-ended engineering.

When it fails on a real gap

Sometimes the product simply does not do the thing. Lead the readout with that, before anyone asks, because the evaluation engineer who watched it fail will contradict a deck of green ticks in the room. Then be precise about where the boundary is: a hard architectural limit, a missing feature with a roadmap commitment and a date you can stand behind, or something achievable with work the customer would have to pay for. Bring a workaround if one honestly exists and quantify what it costs them.

Then let them decide. Some criteria stop being deal-breakers once the sponsor sees the trade-off in the open, and a POC that fails one of three often closes on a narrowed phase one. What kills a deal is rarely the gap; it is the discovery that the gap was known and hidden. If the failure is fatal, say so and withdraw cleanly — the alternative is winning a deal your delivery team cannot honour.

Why "agreed success criteria" is not the same as agreed criteria

Most candidates say they would agree success criteria up front. Almost nobody says who signs and what the pass threshold is, and that is the whole difference. Criteria agreed verbally with a friendly architect drift, and by week three a security lead nobody invited has raised an objection and the readout is being judged against expectations never written down. There is nothing to point at, so the answer becomes "let's extend it".

The related failure is agreeing criteria with the person who wants the product rather than the one who approves the spend. A technical champion will sign anything to get started, then discover their CFO's real question was cost over three years and never appeared in your criteria at all.

Scope a POC around the two or three things neither side can currently predict, with pass thresholds a stranger could adjudicate and a signature from whoever approves the spend. If you cannot get that written down, or cannot get an engineer and real data committed on their side, it is not an evaluation.