Structure

The Anatomy of a Winning POC

A winning POC moves through six phases, and the proportions are not even. Most of the work that decides the outcome happens in the first two phases, before anything is installed. The single most important idea on this page is that the readout is built on day one. Every activity during the POC exists to fill in a slide of the final presentation. If an activity does not map to a readout slide, it does not belong in the POC.

1

Qualification

A short phase that decides whether a POC is the right instrument at all. Not every deal earns one, and a POC run for the wrong reason burns weeks you do not get back.

Mistake: agreeing to a POC because the buyer asked, without checking access to power or budget

Fix: qualify the POC as hard as you qualify the deal, and be willing to propose a smaller proof instead

2

Charter

The agreement on what success means: criteria, scope, timeline, ownership, and the decision that follows. This is where the POC is actually won or lost.

Mistake: jumping to setup because everyone is keen to "just see it working"

Fix: install nothing until the charter is written down and agreed by the customer side

3

Setup

Provision and configure only what the criteria require. Setup is plumbing, not theatre, and it ends when the criteria can be tested.

Mistake: building an impressive showcase environment that goes well beyond the agreed scope

Fix: scope setup to the criteria, and time-box it so it does not eat the evaluation window

4

Guided Execution

The buyer drives and you guide. Each working session produces evidence for a specific criterion, so the readout fills itself in as you go.

Mistake: handing over a trial login and hoping the buyer finds the value alone

Fix: run scheduled sessions, each tied to one or more criteria you are there to prove

5

Mid-point Checkpoint

A formal go, adjust, or stop decision at the halfway mark. It exists to catch a criterion that cannot be met while there is still time to act.

Mistake: discovering in the final week that a criterion was never reachable

Fix: schedule the checkpoint in the charter and be genuinely willing to stop or re-scope

6

Readout

Present the result criterion by criterion, then ask for the decision that was agreed in the charter. The readout is a scorecard, not a second demo.

Mistake: a warm feature recap that never states whether the POC passed

Fix: show each criterion as met or not met, then ask the pre-committed decision question out loud

Framework

The POC Charter: Five Commitments

The charter is a short written agreement you and the buyer sign up to before setup begins. It rests on five commitments. Skip any one of them and the POC develops a predictable way to die. The examples in each card are phrasings you can actually say in the room, not theory.

Commitment 01

Success Criteria

Measurable outcomes, written down, capped between three and seven, and agreed by someone on the economic buyer's side. The difference is between "evaluate the platform" and "ingest dataset X and return query results in under two seconds." Without written criteria there is no definition of done, so the POC cannot pass, it can only continue. What good looks like: every criterion has a number or a yes-or-no test, and the buyer has said out loud that meeting them means a pass.

"Let's write down the three to five things this POC has to prove. If we hit all of them, would you consider it a success?" · "What would you need to see, specifically, to feel confident recommending this internally?"

Commitment 02

Scope

What is explicitly in and what is explicitly out. Scope is the wall that stops a POC sliding into free consulting. Deals die here when "while you're at it, could you also..." quietly turns the evaluation into an unpaid implementation of things nobody has committed to buying. What good looks like: an out-of-scope list that is as clear as the in-scope list, so a new request is a visible trade rather than a silent addition.

"In scope for this POC: these three workflows. Out of scope: the rest, including the production migration. Does that match your expectation?" · "That's a great use case for the rollout. For the POC, can we park it and stay on the agreed scope?"

Commitment 03

Timeline

A fixed end date, a defined check-in cadence, and an agreement on what happens when the date arrives regardless of the state of the work. An open-ended POC has no urgency, and a POC with no urgency is the first thing to slip when the buyer gets busy. What good looks like: a date on the calendar for the readout, set before setup starts, with both sides clear that the readout happens on that day even if a criterion is still open.

"Let's set the readout for the 28th and work back from there. Does that date work for the people who need to be in the room?" · "If we reach the date with one criterion still open, let's agree now how we'll handle that."

Commitment 04

Ownership

A named owner on the customer side with real time allocated, not just a friendly contact who likes the product. A POC without a customer-side owner is the vendor doing homework alone, and homework done alone rarely changes a buying decision. What good looks like: a specific person who has agreed to spend a stated number of hours, attends the sessions, and is accountable internally for the evaluation reaching a verdict.

"Who on your side will own this with me, and roughly how many hours can they give it over the two weeks?" · "I work best when there's one person I'm building this with. Who is that going to be?"

Commitment 05

Decision Commitment

The most skipped commitment of the five: agreement, in advance, on what happens if the criteria are met. This is the question that separates a POC that closes from one that becomes an indefinite pilot. Asking it early feels uncomfortable, which is exactly why so few SEs do it, and exactly why the ones who do win more of the evaluations they run. What good looks like: before setup begins, the buyer has told you what stands between a passing POC and a signature, so the readout ends with a decision rather than a request for "a bit more time."

"If we hit all of these criteria, what would stand between us and moving forward?" · "Assuming this proves what we both expect, what does the path to a decision look like, and who signs off?"

Transition

The Demo-to-POC Bridge

A POC is expensive for both sides, so the first decision is whether to run one at all. The best SEs fight for a POC when it will move the deal and fight just as hard against one when it will not. The two cards below are the test, and the steps that follow turn a strong demo into a signed charter in the same meeting.

Fight for a POC when

The deal is large enough to justify the engineering hours on both sides.
The criteria are real, specific, and reachable inside the timeline.
You have access to someone with the authority to decide once it passes.
The buyer's risk is genuine and a working proof is what unlocks the decision.
There is a named owner willing to spend real time alongside you.

Fight against a POC when

The deal is too small to repay the time the POC will consume.
The criteria are vague, unbounded, or quietly unobtainable.
You have no access to power, only to a friendly evaluator.
It is evaluation theatre for a pre-decided incumbent, and you are the column-fodder quote.
A shorter proof, a guided trial, or a reference call would settle the question faster.

1

Name the POC while the demo is still warm

The moment to propose a POC is the moment the demo lands, not three days later in a follow-up email after the energy has cooled. When a buyer leans in and says "we'd need to see this on our own data," that is the opening. Name the next step out loud and start shaping it together before the call ends.

"It sounds like the real question is whether this holds up on your data. That's exactly what a short, scoped POC is for. Can we sketch out what it would need to prove?"

2

Turn demo reactions into draft criteria

Every "can it also do X?" during the demo is a draft success criterion. Capture them as they happen and read them back at the end as the proposed scope. This does two things at once: it makes the buyer feel heard, and it converts loose enthusiasm into the specific, measurable list the charter needs.

"You raised three things you'd want to confirm: the load time on your volumes, the SSO integration, and the export format. Should those be the criteria for a POC?"

3

Put the decision question on the table

Before you leave the room, ask what a successful POC would unlock. The answer is the decision commitment, captured at the one moment the buyer is most invested. If they cannot answer it, you have learned something important about whether this POC is worth running at all.

"If a POC proves these three things, what happens next on your side? I want to make sure we're both running this toward a real decision."

The go / no-go checklist

The deal size justifies the hours this POC will take from both teams.
Three to seven measurable criteria are written down and reachable in the window.
A named customer-side owner has agreed to real, allocated time.
You have a line to someone who can decide once the criteria are met.
You know, in advance, what a passing POC unlocks.

If you cannot tick all five, do not decline the evaluation, re-shape it: a smaller proof, a tighter scope, or a different next step that you can actually win.

Execution

Running the POC

A good charter can still be wasted by a sloppy run. The operational craft below keeps the evaluation moving, keeps the champion equipped, and brings the whole thing to a clean decision instead of a slow fade.

1

Kick off against the charter, not the product

The kickoff sets the rules of engagement. Restate the criteria, the scope, the timeline, the owner, and the readout date, and get a verbal yes on all five in front of everyone. This is your insurance against the quiet drift that starts when one person in the room remembers the POC differently from the rest.

"Quick recap before we build: three criteria, this scope, a readout on the 28th, [owner] driving on your side. Everyone good with that as the plan?"

2

Run a cadence where every check-in produces something

A status call that produces only reassurance is wasted. Each check-in must produce an artefact: a criterion marked met, a blocker logged with an owner, or a written status the champion can forward upward. A cadence built on artefacts is one you can point back to at the readout, criterion by criterion.

"Each Friday I'll send a one-pager: what's proven, what's in progress, what's blocked, and the one thing I need from your team next week."

3

Surface blockers early and out loud

A blocker found in week one is a scheduling problem. The same blocker found in the final week is a lost POC. The instinct to quietly work around an obstacle so the buyer never sees friction is the wrong one: raise it immediately, name what you need, and put the resolution on the shared status. Buyers trust vendors who flag problems early far more than ones who only ever report sunshine.

4

Treat the mid-point checkpoint as a real decision

Halfway through, stop and make an honest call: go, adjust, or stop. If every criterion is on track, confirm it and keep moving. If one is slipping, decide now whether to re-scope it or drop it. If the POC is clearly not going to pass, a clean stop is far better for the relationship than dragging a doomed evaluation to its end date.

5

Trade, do not add

New requirements will appear mid-flight, often from a stakeholder who was not in the original room. The reflex to say yes to all of them is how a two-week POC becomes a two-month one. Treat scope as fixed capacity: anything new comes in only by trading something out, and you make that trade visible to the owner rather than silently absorbing it.

"Happy to prove that too. To hold the readout date, we'd swap it for one of the original three. Which matters more to you?"

6

Keep the champion armed

Your champion has to sell this internally when you are not in the room. Give them progress they can forward without editing: a short, confident summary of what has been proven so far, framed in their organisation's language and tied to the outcome their leadership cares about. A champion with nothing to forward goes quiet, and a quiet champion is how decisions stall.

7

Run the readout to a decision

The readout is the whole point, and it needs the right people in the room: the owner, and at least one person who can act on the result. Walk the criteria one by one, met or not met, with the evidence you gathered along the way. Then ask the decision question you agreed in the charter. Do not end on "we'll send a summary." End on "these are met, what do you need from us to move forward?"

"All three criteria are met, here's the evidence for each. Back in the charter we agreed this would clear the path to a decision. What's the next step on your side?"

What to Avoid

POC Anti-Patterns

Most failed POCs fail the same five ways. Each has a recognisable shape, a reason it keeps happening, and a fix that lives almost entirely in the charter you wrote at the start.

Anti-Pattern 01

The Science Project

Endless exploration with no criteria and no end date. Everyone is enjoying themselves, the product keeps doing interesting things, and nobody can say what would make it a pass.

It happens because curiosity is more comfortable than commitment, for the SE and the buyer alike. The cost is weeks of effort that prove nothing decision-relevant, because there was never a definition of done to reach.

Write the criteria first and let them bound the work. If an activity does not test a criterion, it is interesting, not in scope.

Anti-Pattern 02

The Free Consulting Trap

Scope creeps until the SE is quietly building and tuning production-grade workloads that no one has agreed to buy. Each new ask seems small in isolation.

It happens because saying yes feels like good service, and the boundary was never drawn. The cost is an SE doing an implementation team's job for free, while the actual buying decision sits exactly where it started.

Make the out-of-scope list explicit, and treat every new request as a trade against the agreed scope, not a free addition.

Anti-Pattern 03

The Ghost POC

The environment is set up, access is granted, and then the customer goes silent. The SE pings into the void while the evaluation quietly decays.

It happens when there is no named owner with allocated time, so the POC is never anyone's actual job. The cost is a dead evaluation that still shows as "in progress" in the forecast long after it stopped moving.

Refuse to start without a named owner who has committed real hours, and confirm that commitment at the kickoff in front of their manager.

Anti-Pattern 04

The Moving Goalposts

The criteria are met, and then they quietly change. A new "must-have" appears just as the old ones are satisfied, and the finish line slides further away.

It almost always signals a hidden stakeholder who was never in the room, or an evaluation that was steering toward a different outcome all along. The cost is an SE who can never win because the target keeps moving.

Lock the criteria in writing, and when new ones appear, surface them as a change: "these are new, what shifted, and who is now involved?"

Anti-Pattern 05

The Eternal Pilot

The POC succeeds on every criterion and then, instead of a decision, rolls into an indefinite unpaid pilot. "Let's keep it running a bit longer" becomes the permanent state.

It happens because no decision commitment was ever secured, so a passing result has nowhere to go. The cost is the worst kind of loss: you proved the value completely and still did not close, because nobody agreed in advance what a win would trigger.

Secure the decision commitment before setup, and at the readout ask the exact question you agreed: if the criteria are met, what happens now?

Self-Assessment

Score Your Last POC

Rate your most recent proof of concept on a 1–5 scale. 1 = this didn't happen. 5 = executed precisely. Be honest, the score only helps if it's accurate.

1. Were the success criteria written down and agreed by the customer side before anything was installed?

No criteria, or agreed loosely after setupWritten and agreed before any install

2. Were those criteria measurable and capped, roughly three to seven, rather than an open-ended "evaluate the platform"?

Vague or open-ended evaluationThree to seven measurable, testable criteria

3. Was scope documented as explicitly in and explicitly out, with a clear line on what counts as out of bounds?

Scope was assumed, never writtenClear in-scope and out-of-scope lists

4. Was there a fixed end date, with a defined check-in cadence, agreed at the start?

Open-ended, no firm dateFixed end date and cadence set upfront

5. Was there a named owner on the customer side with real, allocated time, not just a friendly contact?

Only a friendly contact, no real timeNamed owner with allocated hours

6. Did you secure a decision commitment in advance: agreement on what happens if the criteria are met?

Never discussed what a pass unlocksAgreed in advance what a pass triggers

7. Was the readout outlined on day one, so every activity mapped to a slide you needed to fill?

Built the readout at the endOutlined day one, filled it as we went

8. Did each check-in produce something concrete: a documented result, a resolved blocker, or a status the champion could forward?

Check-ins were mostly reassuranceEvery check-in produced an artefact

9. Did you run a formal mid-point checkpoint as a real go / adjust / stop decision, rather than drifting to the end date?

Drifted straight to the end dateHeld a real go / adjust / stop checkpoint

10. When new requirements appeared mid-flight, did you trade them against scope instead of just adding them, and did the readout end by asking for the agreed decision?

Absorbed new asks; ended with "we'll follow up"Traded scope and asked for the decision

Context

What Shaped This Playbook

The frameworks here are original, but they didn't emerge in a vacuum. These four books shaped how I think about technical validation and the decision that ends it, all available in the SE Resources books section.

Mastering Technical Sales: The Sales Engineer's Handbook

John Care

The reference text for the SE role end-to-end. Its treatment of running evaluations and managing the technical close is the backbone of how most teams think about POCs, and its insistence on agreed criteria before the work begins is the idea this playbook leans on most.

The JOLT Effect

Matthew Dixon & Ted McKenna

A study of why deals stall in indecision rather than losing to a rival. Its lens on customer hesitation is exactly why the decision commitment matters: a POC can prove everything and still die in the gap between a passing result and an actual choice.

Doing Discovery

Peter E. Cohan

Discovery and POC scoping are the same muscle. Cohan's work on separating real, quantified problems from merely interesting ones is what keeps a POC's criteria tied to outcomes a buyer will actually pay to fix.

The Challenger Sale

Matthew Dixon & Brent Adamson

The research on reframing and constructive tension informs how an SE pushes back on a POC that is scoped to fail, and how to hold a firm line on criteria and scope without losing the room.

The POC Playbook