Phase 3 — design and run a POC

What you will learn What a POC is really for, how to set its scope, and the test for "it worked."

The purpose of this phase

Verify the effect with a small pilot and collect feedback.

There is one misconception here.

The purpose of a POC is not to succeed. It is to decide whether to scale.

That difference changes the outcome. Make success the goal and you end up showing only the cases that go well, then failing after you scale. Make the decision the goal and you go looking for the cases that fail.

Four activities

1. Define an MVP scope (quick wins first)

Do not build everything. Cut it down to the most frequent and simplest cases.

With the invoice example:

text

Full scope: 80 suppliers, 12 formats, 400/monthPOC scope: top 5 suppliers, 2 formats, 180/month (45% of the total)           → people keep handling the rest

Covering 45% is plenty to decide with. If there is no effect here, there will be none in the remaining 55%.

How to narrow scope Start from the highest frequency. Start from the hard exceptions and all your time goes there. Exception handling gets attached during the scale-up.

2. Build the AI agent or workflow

This is the part where you actually build. The flow diagram from Phase 2 is the blueprint.

Two things to decide in this phase:

To decide	Example
Where human approval sits	anything over the threshold needs approval
How you learn it was wrong	flagged on the owner's review list after entry

The second matters especially. If you do not know it was wrong, you cannot measure the effect either.

3. User testing and feedback

The person who does the job actually uses it. What they say here is sometimes more important than the POC numbers.

What they say	What it means
"It's faster if I do this myself"	structural problem. Steps probably increased
"What happens in this case?"	exception found. Decide whether it is in scope
"Checking it is a job in itself"	not trusted. Redesign accuracy or approval points
"When can we use this for real?"	a good sign

4. Measure the metrics (time / cost / quality)

Measure by the same method as the numbers recorded in Phase 1. A different method means no comparison.

text

                     Phase 1 (before)   POC resultTime per item        6 min              1.5 min (excl. approval wait)Total hours/month    40 hrs             11 hrs (scaled to POC scope)Errors               12/month           2/monthHuman involvement    every item         18% (over threshold)

Output

POC report & scale-up recommendation

What the report must contain is what did not work, more than what did.

text

1. Result summary (the table above)2. What worked3. What did not ← the most important part   - handwritten invoices have low recognition (6% of the total)   - the first item from a new supplier often gets the wrong account code4. What scaling requires   - route handwritten items to a person   - require approval on the first 3 items from any new supplier5. Recommendation: scale / scale with conditions / stop

Gate — to move on

Did Phase 1's numbers actually move? Are users still using it?

Both must be yes. One out of two is not enough.

Numbers	Usage	Verdict
moved	still used	scale
moved	not used	structural problem. Start with why not
flat	still used	convenient but ineffective. Redesign
flat	not used	stop and return to Phase 1

"Flat + still used" is the trap. People like it so it looks like success, but the metrics are unchanged. Scale it and you only add cost.

Keeping the POC short

POCs run long almost always because the scope grew.

text

POC week 2: "it'd be nice if this case worked too"POC week 4: "while we're at it, let's integrate that system"POC week 8: still in progress

Write the scope down at the start and send every addition to the "scale-up list." Explained as a matter of order rather than refusal, it is generally accepted.

Common misconceptions

"It's a POC — can we build it roughly?"

Do not compromise on quality; narrow the scope. Those are different. A narrow scope built properly makes the decision valid. A wide scope built roughly leaves you unable to tell whether a null result came from the design or from the rough build.

"If it fails, isn't that wasted time?"

Three to six weeks of POC prevented a failed rollout. Compare that to the cost of scaling company-wide without verification and failing six months later. A failed POC is a success — it stopped an expensive mistake cheaply.

Check yourself

1. State the purpose of a POC in one sentence.

Answer

To decide whether to scale. Make success the goal and you show only the cases that go well, then fail after scaling. Make the decision the goal and you go looking for the cases that fail.

2. "The metrics are flat but users keep using it." What is the verdict?

Answer

Redesign. It is convenient but ineffective. The trap is that people liking it looks like success; scale it as-is and you only add cost.

3. What is the most important section of a POC report?

Answer

What did not work. That is where you learn what must be shored up before scaling. A report containing only successes becomes an incident during the rollout.

Now design that POC on one page yourself. Forty minutes → Design a POC on one page