Learning objectives
- Translate aspirations into measurable criteria
- Write a bounded PoC charter
- Report failed and untested criteria honestly
The mental model
A proof of concept needs a finish line. Faster, safer, and easier are useful aspirations, but they are not sufficient criteria for a decision. Define the workload, baseline, measurement, acceptable result, and owner who will judge it. Include operational and usability requirements alongside performance or security. A test that passes technically but cannot be maintained by the customer's team is incomplete. The criteria should be agreed before the result is known, so neither side can quietly move the goalposts. A well-designed PoC can conclude that the proposed approach is unsuitable. That is valuable when it prevents an expensive production mistake.
How it works
Write each criterion as a measurable statement tied to a customer outcome. For example, compare a specified latency percentile for a representative endpoint and region under a defined load, while requiring correct authorization and an acceptable error rate. Label all sample thresholds as illustrative until the customer agrees them. Avoid a single aggregate score that hides a failed safety requirement.
A PoC charter should define scope, exclusions, data, owners, schedule, instrumentation, acceptance criteria, and rollback. Include a baseline run and a changed-condition run that differ in a controlled way. Record configuration and measurement definitions so results are reproducible. Add failure tests for the riskiest assumption: identity denial, origin failure, cache invalidation, or a dependency timeout. Decide in advance what happens if a criterion fails or evidence is insufficient. The final readout should show results, limitations, operational implications, and a recommendation. General customer engineering practice treats the PoC as a decision instrument; it should not silently expand into an indefinite implementation project. When new requirements appear, assess whether they change the decision and explicitly revise scope rather than absorbing unlimited work.
Applied example · hypothetical
Hypothetical branching scenario: a customer says the PoC must make the app much faster. Weak response: We guarantee a dramatic improvement. Strong response: Which journey and percentile matter, and what baseline is acceptable? If the customer chooses public catalog pages, test cacheable traffic and freshness. If they choose personalized analytics, measure origin computation and data access. If no instrumentation exists, add a baseline phase. The same phrase produces different test plans, and the criteria prevent a favorable static-asset result from being presented as proof about every API.
In a customer engagement
For a Cloudflare PoC, confirm the exact product configuration and available features, then tie each test to the customer's architecture. Include a controlled hostname or traffic cohort, representative clients, and a rollback owner. Present a result table that separates passed, failed, and untested criteria. This keeps technical evidence useful to the customer and the account team.
Interview relevance
In an interview, design a PoC around the most important uncertainty. Explain what you would deliberately exclude and why. State how you would handle a failed or inconclusive result. This demonstrates scope management and integrity, both of which matter when technical evaluation is happening under commercial time pressure.
Common mistakes
- Choosing thresholds after seeing results
- Hiding safety failures inside an average score
- Allowing an evaluation to expand without a decision
Key terminology
PoC charter — The agreed scope, hypothesis, tests, owners, criteria, and decision process for an evaluation.
Exit criterion — A condition that determines whether a phase or evaluation can conclude.
Scope creep — Uncontrolled expansion of work beyond the agreed evaluation or project boundary.
Explain it without the page
- What would make your PoC inconclusive rather than failed?
- Which criterion must pass even if performance improves?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.