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:

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:

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.

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.

Output

POC report & scale-up recommendation

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

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.

"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.

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