There is a simple test for whether a proof of concept was worth running: at the end, can the executive sponsor make a build or no-build decision and defend it? If the answer is a demo, some enthusiasm and a request for more budget, the PoC did not prove anything - it just spent less than a project.
Experimentation in the GIVE framework is our existing PoC methodology made explicit: time-boxed, tied to a value driver, with strict acceptance criteria and tested assumptions. What makes it work is not the build. It is the artefacts around the build.
The short version: a real PoC is time-boxed, tied to a named value driver, and signed off by the exec sponsor before it starts. It produces five things: a PoC overview, a technical validation log, an assumptions register, a solution canvas, and - if the answer is yes - the epics and user stories that take it to build. The decision is the deliverable.
Before anything is built: the PoC overview
Every PoC starts with a one-document contract with itself: the PoC overview. It categorises the PoC, sets what is in and out of scope, names the measure of success, and lists the assumptions being tested and why. Then it goes to the executive sponsor for sign-off - not as a courtesy, but because a PoC without a sponsor's signature is an experiment nobody has agreed to act on.
The overview is where the two questions that matter get asked in writing:
- Can we? The technical question. Does this work reliably, with our data, in our environment?
- Should we? The business question. Even if it works, does it move the value metric we agreed on?
During: validations and assumptions
Two artefacts run through the PoC itself.
The technical validation log records everything not yet understood being proven. Even if an API's documentation says something is possible, we prove it - and each validation links back to the value metric it protects. The log is what stops "it should work" surviving into a build budget.
The assumptions register holds the business assumptions, tested explicitly. The bluntest one is also the most useful: if this project costs X for a value of Y, would you invest? Asking that during a two-week PoC costs nothing. Discovering the answer during month four of a build costs the build.
The solution canvas - the same tool we publish on this site - holds the shape of the solution as it firms up.
After: a decision, then the handover pack
The PoC ends with the internal conversation and a decision with three honest outcomes:
| Outcome | What it means |
|---|---|
| Go to build | Write the epics, user stories and acceptance criteria and hand to delivery |
| Improve, then decide | The idea survived but the approach needs another pass |
| Stop | The assumptions failed - the cheapest possible time to find out |
A stopped PoC with its reasons on the council's decision log is a good outcome. It is the entire economic argument for experimentation: keep the cost of each experiment low enough and you can afford to be wrong often, which is how you find the things that are right.
When the decision is go, the epics and user stories are the bridge out of the framework entirely - into delivery, which sits after the Accelerator on purpose. That boundary is covered in the GIVE framework.
The non-negotiables
Everything above compresses to five rules we hold on every PoC: it is time-boxed; it has strict acceptance criteria; it is tied to a value driver; its assumptions are tested; and the exec sponsor signs the overview. Relax any one of them and you are back to running a small project and calling it a proof.