How do you scope a proof of concept (POC) so it's useful and doesn't drag on?

30-second answerSay your answer out loud first, then reveal.

Time-box it (typically 2–4 weeks). Define one clear question the POC must answer ("Can we extract these 12 fields from real invoices with ≥ 90% accuracy?"), use real customer data, and agree on in-scope vs out-of-scope items, success and exit criteria, who provides what (data, SME time, access), and what happens if it succeeds (the pilot plan and decision owner). Avoid building production infrastructure in a POC, but don't use toy data either.

POC charter template

Item	Example
Question to answer	Can AI draft accurate first responses for Tier-1 email tickets?
In scope	English emails, 5 top categories, drafts reviewed by agents in a sandbox
Out of scope	Auto-sending, other languages, CRM write-back
Data	2,000 historical tickets + KB articles by day 3
Customer commitments	2 SMEs × 4 hrs/week for labelling and review
Success criteria	≥ 70% drafts rated "send with minor edits" on 200 eval tickets
Timeline	3 weeks; checkpoint at end of week 1
Decision	VP Support decides on pilot by week 4

Pitfalls to avoid

Endless POC: no exit criteria, so it keeps expanding. Insist on a decision meeting.
Toy demos: synthetic or cherry-picked data gives false confidence.
Hidden blockers: security review or data access discovered in week 3. Start those processes on day 1, in parallel.
Success with no path forward: no budget or owner for the pilot. Confirm the next step before starting.

PreviousWhy is building an eval set with the customer so important, and how do you do it?

You understood something today that you didn't yesterday.

How do you scope a proof of concept (POC) so it's useful and doesn't drag on?

POC charter template

Pitfalls to avoid

Related