Proof of Concept
A deliberately bare, internal experiment built to answer the one critical question a concept depends on — before committing to build it.
The PoC is not a product. It is not a prototype. It is a proving rig. It answers one question, then it is discarded. The knowledge it produced is what carries forward.
What it is
A proving rig, not a product. Built to answer one question. Typically discarded after.
A Proof of Concept is a deliberately minimal, internal experiment built to answer the one technical question a concept depends on before committing to build it. It is not a product, not a prototype, and not the beginning of the production system. It is a proving rig: bare enough to answer its question, rough enough to be built fast, and typically discarded the moment it has served its purpose. The proof was the point. The artifact was not.
The PoC’s defining discipline is scope. It contains only what is needed to answer the one critical, genuinely uncertain question: the technical bet the concept stands or falls on. Every component in the rig exists only because it is necessary to generate the verdict. A component that does not serve the question does not belong. This is not minimalism for its own sake — it is minimalism as a proof of seriousness about what is actually being tested.
The output of a PoC is a verdict, not a deliverable. It works. It does not work. Or: it works under specific, named conditions that you must now carry forward. That qualified verdict — especially its conditions — is often more valuable than a clean pass, because it tells you exactly where the signal breaks down and what assumptions you must not import into what you build next. The rig is discarded. The knowledge carries forward: to a prototype, to an MVP, or to a decision to stop before spending more.
The proving rig — explore what it includes, excludes, and produces.
Click the parts of the rig to understand the discipline behind each choice.
Each element of a PoC is a deliberate decision: what is included, what is absent, and what the verdict means. Explore the rig to see the discipline behind each one — including the anti-pattern that quietly turns a PoC into something else.
When to deploy it
When you have a specific, technically uncertain question that a concept stands or falls on — and building first would be the expensive way to find out.
Use it when
- →There is a specific technical question the concept depends on that is genuinely uncertain and that a bad answer would make the rest of the build wasteful.
- →The cost of getting that question wrong is high relative to the cost of building a bare rig to answer it now.
- →You can name a precise, answerable question and a pass/fail threshold before the test runs.
- →You are early enough that the answer could reshape what you build, or lead to stopping altogether.
Do not lean on it when
- ×The technical question is not genuinely uncertain — if you already know it is possible, you do not need a PoC, you need to build.
- ×You are using "PoC" as a label to avoid committing to production quality, while building something you intend to ship. That is not a PoC; it is a product with technical debt baked in.
- ×The question cannot be answered by internal experiment alone — some questions (market adoption, user desirability) require real users and belong to a prototype or pilot instead.
- ×There is no clear pass/fail threshold. If you cannot define what "it works" means before you start, you will rationalise whatever result you get.
The honest limit: the PoC answers the question you point it at. If the question is wrong — too vague, not the most critical bet, or tested under conditions unlike reality — the verdict is misleading even if technically accurate. The discipline is in the question, the threshold, and the integrity of the conditions. Get those right before you build the rig.
How it works
Five moves, from naming the question to discarding the rig and carrying the knowledge forward.
Name the one critical question precisely.
A PoC starts with a specific, answerable question — not a general hope. "Can this work?" is not a question a PoC can answer; "Can we predict delivery delays with accuracy above 75% using existing data?" is. The precision matters because it determines what gets built and what counts as a verdict. A vague question produces a verdict you will rationalise rather than use.
Name the pass/fail threshold before you start.
Set the criterion for a verdict before the rig runs — not after seeing the results. This is the discipline that prevents motivated reasoning from turning an ambiguous result into a "pass" because the team wanted it to work. If you cannot name a specific threshold in advance, you do not yet have a testable question.
Build only what answers the question.
Assemble only the components necessary to generate the verdict. No interface, no extra features, no production engineering, no completeness. Every addition that does not directly serve the critical question is scope drift — it costs time without buying more certainty about the one thing being proved. This discipline is harder than it sounds: there is always a temptation to make the rig slightly more useful, or slightly more complete.
Test under conditions close enough to reality to matter.
Use real data, real infrastructure, and real conditions wherever possible — or be explicit about what you idealised and why. A PoC that proves the question only in a clean sandbox environment has answered a slightly different question than the one you have in production. The proof conditions must be named as part of the verdict.
Deliver the verdict with its conditions. Discard the rig.
Communicate the result precisely: what was proven, under what conditions, and what remains uncertain. Name the conditions of a qualified verdict explicitly — they are not a failure of the PoC, they are its most valuable output, because they tell you what to build and what to avoid. Then discard the rig. The knowledge it produced carries forward; the artifact does not.
Best practices
What good looks like — and the failure modes that quietly turn a PoC into something else.
When it goes well
- ✓The question is specific and the pass/fail threshold is set before the rig runs — not after seeing the results.
- ✓The rig contains only what is needed to answer the question, and nothing else.
- ✓Real data and real conditions are used, or the idealisation is named explicitly as a limit of the verdict.
- ✓A qualified verdict — it works under these conditions, degrades under those — is treated as valuable, not as a partial failure.
- ✓The rig is discarded after the verdict, and the knowledge carries forward into what is built next.
The failure modes
Growing the PoC into the production system.
The most common and costly failure. The rig was built to prove, with shortcuts that are deliberate and appropriate for an experiment. Those shortcuts are not appropriate in production code. Growing the PoC into the product carries all of them into something that must be maintained, scaled, and supported. Discard the rig. Build the product properly from the knowledge the rig produced.
Scope drift — adding things that don't serve the critical question.
The moment the PoC acquires an interface, an extra feature, or some polish, it has become a half-built, unvalidated product. Each addition feels cheap at the time. They accumulate. The discipline: if this component does not directly help answer the one question, it does not belong. Every addition that doesn't serve the question is time that didn't buy certainty.
Not naming the threshold before running the test.
Without a pre-committed threshold, a motivated team will rationalise whatever result they get. "78% accuracy — that's promising enough" and "78% accuracy — we set 80% as the target, and this tells us why" are entirely different verdicts. Set the threshold before the rig runs. The discipline is in the commitment, not just the number.
Using "PoC" as a label for something you intend to ship.
If the intent is to ship it, it is a product. Calling it a PoC to avoid production-quality expectations just means the shortcuts will find their way into production. The PoC label implies a clear decision: this artifact will be discarded. If that decision has not been made, the work is not a PoC.
Testing in too-clean conditions and importing that as reality.
A PoC proved on curated, clean data in an ideal environment has proven a slightly different thing than what will run in production. Name the proof conditions precisely. A qualified verdict that works under named conditions is more useful than an unqualified "pass" that obscures where the signal degrades.
Logistics
Small team, short timeframe, real data — and a pre-committed verdict criterion.
A PoC typically involves a very small team: one to four people, usually technically skilled in the domain being tested. Timescales range from a day for a narrow technical question to a few weeks for a more complex proof — but always bounded. If the PoC is taking months, the scope has drifted or the question was not precise enough.
Team size
1–4 people
Small, technically skilled in the domain of the question
Timeframe
Days to weeks
Bounded strictly; months means scope has drifted
Audience
Internal only
No external users; the rig is not a product experience
Remote vs in-person
The proving rig itself is typically built and run entirely remotely — there is no in-person element to the experiment. The human-judgment moments (naming the question, interpreting the verdict, deciding what to build next) benefit from close collaboration but do not require physical co-location. PoCs work well across distributed teams.
AI & Proof of Concept
AI can build the rig dramatically faster. The judgment calls — which question, which conditions, what the verdict means — stay human.
The PoC is one of the places where AI gives genuinely substantial time leverage: the rig is tightly scoped, outcome-focused, and internal — precisely the conditions where AI coding assistance compounds speed most. Toggle to see where that leverage is real and where the human role remains load-bearing.
In practice
A logistics team asks: can the data predict delays? See what a well-run PoC produces — and what AI changes about the time it takes.
A well-formed PoC question, a threshold set in advance, real messy data, and a qualified verdict that reshaped what to build. See the traditional approach first, then compare what AI changes — and what it does not.
The one question — named precisely
The team resisted the temptation to ask “will our delay-prediction product work?” — a question with no provable answer at this stage. Instead they named the critical uncertain thing: “Using the existing route, weather, and driver-history data, can we predict delivery delays more than 24 hours in advance with accuracy above 75% on the last 18 months of real data?”
Crucially, they also named the pass/fail threshold in advance: accuracy above 75% on real historical data. Not “it feels promising” — a number, set before the test ran.
What the rig included
- →A data pipeline to pull and normalise three existing data sources
- →A simple ML model (gradient boosted trees) to generate predictions
- →Evaluation logic: compare predictions against actual outcomes
- →A result readout: accuracy score, breakdown by route type
What it excluded (deliberately)
- ×No interface — results read from a notebook, not a dashboard
- ×No real-time data feeds — tested on 18 months of historical data only
- ×No routing logic — the PoC proved prediction, not the full system
- ×No production engineering — would be discarded after
Tested on real messy data — not cleaned samples
The team insisted on testing with 18 months of actual, uncleaned operational data — the same data the system would eventually work with. They resisted the temptation to clean it first, which would have made the rig succeed in conditions unlike production. The messy data was the point: if the signal wasn’t strong enough to work in messy conditions, that was a fact worth knowing now.
The verdict — qualified and useful
Worked for standard domestic routes (83% accuracy). Degraded significantly for cross-border deliveries (58% — below threshold).
That qualified verdict was more valuable than a clean pass would have been. The team now knew: the prediction signal was real for domestic routes, but cross-border logistics data had a different structure that the current data sources couldn’t capture well enough.
The rig was discarded. The knowledge carried forward — reshaping what to build: a domestic-first product, with cross-border as a phase-two problem requiring different data sources. That decision, made now, saved months of building the wrong thing.
The verdict, including its conditions, was the deliverable. Not the notebook. Not the model. The knowledge.
Framework connections
Where the PoC sits inside the frameworks that shape delivery.
Double Diamond
Develop / DeliverA PoC typically belongs at the boundary of the Double Diamond's second diamond — at the end of Develop, when a concept is being tested for feasibility before committing to delivery. It can also appear early in Deliver: before building begins in earnest, a PoC de-risks the hardest technical assumption. The Double Diamond's diverge-converge rhythm makes explicit where the PoC sits: just before convergence on what to build.
Lean Startup
BuildIn the Lean Startup's Build-Measure-Learn loop, a PoC occupies the earliest, smallest possible Build: build only what tests the riskiest assumption. It is the instrument that generates the data point for the Measure stage. The Lean Startup's discipline — build the smallest thing that tests the most critical uncertain assumption — is the PoC's exact logic applied to the BML loop.
Agile Innovation
Sprint (Technical Spike)In Agile Innovation, a PoC maps directly to the concept of a technical spike: a short, focused piece of work designed to resolve a specific technical uncertainty before it is baked into a sprint commitment. A spike is a team-sanctioned PoC. The key Agile discipline applies: the spike is time-boxed, discarded after answering its question, and its findings feed the backlog — not a living codebase.
Front-End of Innovation
Feasibility AssessmentThe Front-End of Innovation's feasibility assessment asks: can this work technically? A PoC is one of the primary instruments for answering that question. Where the FEI framework defines the questions to answer (Is it technically feasible? Is it economically viable?), the PoC defines how to answer the technical one: build a bare, focused experiment that proves or disproves the critical technical assumption.
Related methods
The PoC in context — and the staircase it belongs to.
The next step up the staircase of increasing realness. A PoC asks: can this work internally? A prototype asks: does this concept work for people? The prototype is rougher and more visible than a finished product, but it is designed to be used by people — unlike the PoC, which is internal and deliberately bare. The PoC de-risks the hardest technical bet; the prototype de-risks the concept with users. They sit in sequence, not competition.
Where the PoC tests technical feasibility (can this work?), concept testing tests desirability (do people want this?). They address different risks and should not be confused. A team that runs a successful PoC has proven the technical hard part is possible — they still need concept testing to validate that what is possible is also wanted. Both are de-risking instruments aimed at different bets.
A well-formed How Might We question can help crystallise the PoC question: HMW reframes problems into opportunity statements; the PoC then identifies which technical assumption underpins the most promising answer. The HMW discipline of scoping a single well-bounded question maps naturally onto the PoC discipline of naming one critical uncertain thing. Use HMW to clarify direction; use the PoC to prove it is technically reachable.
Assumption Mapping helps identify which bets to prove first: it maps assumptions by importance and certainty, surfacing the ones that are both critical and genuinely in doubt. The output of an Assumption Mapping session can directly feed the PoC question — the most important, least certain technical assumption is the right candidate for a PoC. Use mapping to choose the question; use the PoC to answer it.
The Staircase of Increasing Realness
The PoC, prototype, MVP, and pilot form a staircase of increasing realness and commitment. PoC: can it work? (internal, discarded). Prototype: does the concept work for people? (rough, with real users). MVP: will people adopt the smallest real product? (smallest shippable thing). Pilot: does it work at limited real-world scale? Holding these distinct is one of the most valuable disciplines a delivery team can maintain. Conflating them means spending prototype money on PoC questions, or MVP effort before the concept is validated.
Sources
The Lean Startup — Eric Ries (2011)
Foundational treatment of build-measure-learn and the importance of the smallest experiment that tests the riskiest assumption. The PoC is the Lean Startup's Build step in its most minimal form.
Testing Business Ideas — David Bland & Alexander Osterwalder (2019)
A comprehensive playbook for de-risking assumptions with appropriately-sized experiments. Provides specific experiment types and evidence strength ratings — the PoC sits at the technical end of its experiment spectrum.
Escaping the Build Trap — Melissa Perri (2018)
Clear analysis of what happens when organisations build without adequately de-risking first — and the structural and cultural conditions that lead to it. The PoC is one of the primary instruments for avoiding the build trap at the technical level.