Pre-Sales: Zero to Hero — Proof of Concept / Proof of Value

MOD 11

Proof of Concept / Proof of Value

The most expensive, highest‑risk tool in the pre‑sales kit — reach for it deliberately, not by default.

When to run one

A POC is justified when a genuine, material doubt remains that only hands‑on evidence can resolve — technical feasibility against their real data, integration with a specific legacy system, performance at their actual scale. It is not justified as a default "let's just try it" step, or as a way to avoid a harder qualification conversation about budget or authority. An unscoped POC is where deals go to stall for months.

PoC vs. PoV — not the same question

The two names get used interchangeably, and the deals that stall are often the ones where they shouldn't have been. A Proof of Concept answers "does this work, technically, in our environment?" A Proof of Value answers a harder, separate question: "does this produce enough business return to justify buying it?" Running a technically flawless POC when the economic buyer's actual doubt was commercial doesn't retire their doubt at all — it just produces evidence for a question nobody was asking.

	Proof of Concept	Proof of Value
Question it answers	Can this work in our environment?	Does this justify the investment?
Primary audience	Technical evaluators — IT, security, integration owners	The economic buyer and the business stakeholders who feel the cost of the status quo
Evidence produced	Feasibility, integration success, performance under real conditions	A quantified business outcome, tied to Module 14's ROI/TCO discipline
Risk it retires	Technical and integration risk	Commercial and career risk — will this actually pay off, and will I look right for recommending it
What a good one requires	Their real data, their real environment, their real constraints	A baseline measurement of the current state, agreed before the evaluation starts — you cannot prove value against a baseline nobody wrote down

Diagnose which one the deal actually needs before scoping anything: if the doubt is "will it break on our stack," run a POC. If the doubt is "is this worth the money and the change," a technically perfect POC won't touch it — that needs a PoV, with the baseline and the business KPI agreed in writing before day one, using the same success‑criteria discipline below.

Scoping discipline

Before anything is built, agree in writing: the specific success criteria (ideally 3–5, each measurable), the exact scope (what's in, explicitly what's out), the timeline, who evaluates the result, and — critically — what happens if the criteria are met. A POC without a pre‑agreed "yes, then we buy" commitment from the economic buyer is just free consulting. Full template at Template 5.

One qualification on thatFrom Mod 03+: if the customer wants to move and is frightened rather than uninterested, demanding a signed commitment before you will prove anything is pressure applied to the wrong problem. With an indecisive buyer the POC's job is to retire one specific fear, so the commitment worth seeking is "if this criterion is met, what would still be unresolved for you?" — not a pre‑signed order. Keep the hard version for buyers who have shown no intention of moving.

Scope creep, a.k.a. the "science fair"Watch for success criteria quietly multiplying mid‑POC ("could you also just show..."). Every addition needs the same rigour as the original scope — write it down, get it agreed, or say no. An unbounded POC signals an unqualified deal more often than it signals genuine interest.

Closing it out

End with a formal readout against the original criteria, not a demo of everything that happened to get built. Map each criterion to met/not met/partially met with evidence, and drive explicitly to the next commercial step that was agreed at the start.