Feasibility assessment and PoC design

Read these first

• Problem selection
• Building a golden dataset

What you will know

• Define kill criteria before a proof of concept starts

  Use measurable thresholds for quality, latency, cost, safety, or integration effort so results cannot be reinterpreted after the demo.

• Choose what to prototype to learn the most, fastest

  Prototype the riskiest assumption first, not the easiest part.

• Kill a PoC that met its criteria for being killed

  A failed experiment should end the work or trigger a documented pivot rather than invite more investment because code already exists.

• Explain what a PoC proves and what it cannot

  A PoC proves feasibility under favourable conditions; it does not prove production readiness.

• Resist a PoC becoming production by default

  Separate experimental code, operational controls, and ownership from any later production decision so convenience does not become approval.

Chapters

1. 1

   A kill criterion needs a number, a frozen set, and a date

   "If accuracy on the frozen 200-case set is under 85% in two weeks, we stop" is a criterion; "if quality is not good enough" is a negotiation waiting to happen. Thresholds have to exist before the first line of prototype code, because after the demo every number acquires an explanation. What makes one binding is not its wording but its provenance: a named sponsor who agreed to it in a written artefact, a stated owner of any change, and the shared understanding that moving the bar after seeing results is itself a recorded decision rather than a conversation. You will write criteria across quality, latency, cost, safety and integration effort for a supplier invoice extraction PoC, and name the one you expect to be argued with.

   Read chapter
2. 2

   Prototype the assumption whose failure invalidates the rest

   A system that needs a new UI, an integration with a legacy SOAP service and extraction from scanned handwritten forms has exactly one component that can end it, and it is not the UI. Building the easy part first produces visible progress and no information. Here you rank a proposal's assumptions by how much of the plan dies if each one fails, then spend the prototype budget at the top of that list.

   Read chapter
3. 3

   18 out of 20 is consistent with anything from 70% to 99%

   A PoC that scores 18 of 20 has not measured accuracy; it has produced a number whose interval spans the difference between shipping and not shipping. Before a threshold means anything you need to know how many cases it can actually resolve and how much run-to-run variance sits underneath it. Sample size is what makes a kill criterion binding rather than rhetorical when the result lands near the line.

   Read chapter
4. 4

   A PoC proves capability under the conditions you chose

   Passing means the capability exists on curated inputs, with no rate limits, no adversarial users, and an engineer watching every run. Those conditions travel invisibly into production, where they become assumptions: the input distribution widens, the watcher leaves, and the happy path turns into the contract. This chapter separates what a successful PoC licenses you to claim from what it does not, and writes its favourable conditions down explicitly.

   Read chapter
5. 5

   The next model release is not a reason to keep spending

   78% against a precommitted 85% bar is a fail, and the sponsor's belief that the next model closes the gap may well turn out to be right. The answer is not to reopen the bar but to convert the belief into a dated, cheap retest against the same frozen set, and to stop work in between. A recorded decision naming what failed, and under which conditions, is what makes that pause reversible.

   Read chapter
6. 6

   Convenience becomes approval when nobody names an owner

   Prototype code reaches production not by a decision but by the absence of one: it exists, it appears to work, and nobody has been asked to own it. Keeping the experiment separable, with its own repository, credentials and no write path into production data, preserves your ability to say no later. Asked what you insist on before it ships, know which two demands matter most and which you concede.

   Read chapter
7. 7

   Promotion is a list of preconditions, and you will get only some of them

   Refusing promotion by default is the defensive half; the other half is naming what the prototype has to become before it is a product, so the negotiation is over a list rather than a mood. The candidates are an owner who is on call, the frozen eval set wired into CI so a regression is visible, cost caps and rate limits, a kill switch and a rollback path, logging and data retention, and the one only this topic contributes: retiring the PoC's favourable conditions one at a time, starting with the input distribution and the engineer who watched every run. Rank them yourself before someone asks which two you keep.

   Read chapter