A successful proof of value is not a proof of scalability

Insurance has developed a shared vocabulary for innovation that almost everyone uses, yet very few people define those common phrases in the same way.

Proof of Concept (PoC), Proof of Value (PoV) and production readiness are used interchangeably in steering papers, board updates and supplier discussions, even though insurers and technology providers may be using those terms to answer very different questions.

That confusion is not merely semantic. It is one of the main reasons the industry keeps producing successful pilots that never become part of the business. While a PoV indicates that an insurer that it has found something worth scaling, that does not automatically mean the insurer is capable of scaling it. Those are two entirely different things, and the gap between them is where a substantial proportion of insurance innovation potential is quietly lost.

The argument is straightforward. A successful PoV was never designed to prove scalability. It should test value in business-as-usual conditions that resemble the company’s real operating environment, and surface the barriers likely to reappear across other use cases, territories or regulatory regimes. Barriers that cannot be solved during the experiment should still be named, owned and treated as explicit constraints, rather than being ignored or dismissed, only to resurface as fundamental issues post-approval.

Three questions, three different experiments

The Proof of Concept asks: can it work?

A PoC tests technical and functional feasibility: can the technology do what the provider claims in the insurer’s real environment? In motor claims, for example, that might mean identifying damages accurately from images, estimating repair requirements, and producing an output quickly enough to fit the existing customer journey.

A useful PoC, therefore, tests whether the solution can:

• work with realistic data and cases from the insurer’s existing environment
• produce usable output at speed, with accuracy that users can trust
• integrate with the current technology estate
• satisfy baseline security and data requirements

The output of a PoC is a single sentence: yes, this technology works.

The Proof of Value asks: is it worth doing?

A PoV asks whether implementation is commercially worthwhile. Rather than technical capabilities, its KPIs related to business outcomes such as:

• handling time, straight-through processing and cost per claim
• fraud detection and customer experience
• operational capacity and indemnity or operating costs
• whether the resulting value clears the insurer’s investment

Once a technology has been proven at several insurers, providers reasonably resist another long PoC and push towards PoV. The risk is that the commercial question is answered on unverified technical foundations, while the third question (whether the value can survive scale) remains untouched.

The question nobody runs an experiment for: can we repeat this under normal conditions?

Most PoVs are designed vertically. Can we make this one solution work, for this one use case, in this one business unit, in this one territory? It’s an approach that reduces uncertainty and keeps costs down, ensuring that pilots don’t escalate into enterprise programmes before they’re proven. However, the difficulty is what happens next.

The moment a PoV succeeds, the organisation asks a completely different, horizontal question: can we make it work for different systems, processes, regulations, people, economics, business units and countries? The original experiment was never designed to answer that. It was designed to answer whether the idea had merit at all.

Don’t wait until a PoV succeeds to start thinking about scale. Design the PoV backwards from the conditions required to scale.

Why successful pilots fail in business as usual

There is a second, less comfortable reason PoV success is a poor predictor of production survival. Namely, PoVs are often tested under conditions that favour success. The innovation team has staked credibility on the idea, the supplier is competing for a contract, and the sponsoring executive has advocated for it internally.

So, the pilot gets executive air cover, hand-picked and motivated users, carefully selected or manually cleaned data, disproportionate supplier support, and exceptions resolved by hand as they arise. The experiment proves the proposition under favourable conditions rather than deliberately discovering the conditions under which it fails. That is dangerous, because production use cases present precisely the types of challenges and operating realities that the experiment removed.

If a PoV requires six senior people from the supplier, manually cleaned data, a hand-picked group of enthusiastic claims handlers and daily intervention from the innovation team, the insurer has not demonstrated a scalable solution, but what exceptional people can achieve under exceptional conditions.

It is for this reason that the PoV should always be designed and trialled in a way that replicates the business-as-usual environment as closely as possible. Tests should include ordinary staff rather than volunteers, real data with real defects, genuine exception rates, realistic supplier involvement, and volumes that at least gesture towards production. Every departure from such conditions creates a caveat that will likely be discovered later, at far greater cost, by someone with less patience.

Where scaling actually breaks

Scaling failures tend to cluster around technology portability, process variation, regulation, economics, operational capacity, adoption, ownership and governance. The PoV should expose which constraints arise at scale, what evidence is missing, and who in responsible for the unresolved work.

A proposed scale-readiness stage: Proof of Scalability

Based on that diagnosis, we propose adding a distinct scale-readiness stage between PoV and scale: a Proof of Scalability (PoS). Here, a typical sequence would be:

1. Proof of Concept: can it work?
2. Proof of Value: is it worth doing?
3. Proof of Scalability: can we repeat this value under normal conditions, elsewhere?
4. Scale: replicate across different different systems, processes, business units and countries.

In this proposed framework, PoS is not another lengthy pilot, but a formal gateway based on evidence collected during a properly-designed PoV.

A scale-readiness test in five dimensions

The PoS gateway should remain simple enough for a steering committee to apply in practice. Five dimensions, each with a small number of questions, need to be addressed before an innovation can be declared successful:

• Economics: do the returns still work at scale across markets once local assumptions change?
• Technology: can the architecture, data model and integrations travel, and which components are genuinely reusable?
• Operations: can the solution run under business-as-usual conditions without extraordinary support, including at materially higher volume?
• Organisation and people: will ordinary users adopt it, what behavioural changes are required, and who owns scaling post-pilot?
• Regulation and governance: which approvals, privacy constraints or model-risk requirements reappear at enterprise scale or in other territories?

Two questions become relevant across all five dimensions. First, what are we doing in the pilot that could not realistically happen in business as usual? And second, if this works spectacularly well, what happens next, and who owns that outcome?

If nobody can answer the second question before the PoV begins, the organisation is not yet ready to run the PoV.

The honest third option

Scale readiness does not require every barrier to be removed during the PoV.

The organisation needs to make each barrier explicit and choose deliberately: solve it now, accept it for later with an owner and a rough sense of cost, or conclude that the solution may not fit that environment.

Discovering and properly dissecting barriers after the business case is approved is where the failures this framework is designed to prevent can arise.

Ownership: sponsorship is not the same as accountability

Executive sponsorship is useful, but it does not answer who owns the work after an experiment. Before a significant PoV starts, three responsibilities should be clarified:

• The Problem Owner: owns the business outcome the innovation is meant to improve
• The Scale Owner: accountable for what happens if the experiment succeeds
• The Executive Champion: removes enterprise barriers that neither of the other two can reach

Having a Scale Owner is particularly important because it changes the incentive structure. Someone enters the PoV with the specific goal of considering the consequences of success, so scale requirements are at the front of the conversation, rather than being postponed until later down the line.

From innovation theatre to an innovation capability

Insurance innovation often separates discovery and validation from industrialisation. Business ownership arrives late, experimentation budgets stop before production, local wins create assets other teams cannot reuse, and “pilot completed” becomes a success measure even when enterprise value never follows.

This creates an innovation theatre with a backstage: labs, partnerships and pilots are visible; architecture, data, procurement, security, compliance, operating models and budgets sit behind them. The backstage determines whether a promising experiment survives business as usual.

A stronger model starts with high-value business frictions, tests failure hypotheses alongside value, applies scale readiness before declaring success, and expands in waves that leave reusable assets behind. Each implementation should make the next easier.

Consider which metrics matters

Many innovation scorecards count ideas, startups, PoCs and successful PoVs. However, these activity measures can often falsely indicated positive results, while enterprise value stays flat.

Better metrics include time from problem to validated value; time from validated value to production; the proportion of value captured; expansion beyond the first use case; and the cost and time taken to achieve a second deployment.

One of the most revealing practical metrics is that time to the second use case. If the first implementation takes twelve months and the second takes another twelve, you’re deploying a technology on a case-by-case basis. However, if the first takes twelve months, the second takes four months, and the third takes six weeks, you’re building a capability.

In this sense, it’s a metric that marks the handoff from scale readiness (whether expansion is viable) to industrialisation (whether the next product, programme, entity or workflow can inherit a reusable operating foundation instead of recreating the implementation effort).

Insurance has two forms of scale: volume and variation. Volume means more policies, submissions, claims or transactions. Variation arrives through new products, programmes, carriers, entities, jurisdictions, approval structures, reporting obligations and workflows. A system can handle ten times the volume and still require major redevelopment when the business model changes.

Start narrow. Architect broad.

In DICEUS insurance platform work, modular designs have been used to separate policy, claims, billing and other operating capabilities, allowing expected changes to be introduced without rebuilding the entire environment. That experience sits behind the principle: start narrow, architect broad.

Scope the first release narrowly and design for the next known variations. Core data relationships, ownership, auditability and key interfaces need consistency; product rules, workflows, permissions, documents, reporting and approval paths need controlled flexibility. Normal growth should not trigger another transformation project.

Where variation becomes visible

For an MGA, the test comes with the next programme. A different carrier, rating approach, commission model, document set or delegated authority arrangement can expose how much of the first implementation is genuinely reusable.

The executive question is simple: can the second programme launch materially faster than the first? If a first programme takes nine months to launch and the second still takes eight, the first implementation has created very little operating leverage.

Captive management is even more revealing because variation is a big part of the captive operating model. If the next captive brings a different programme structure, allocation method, approval hierarchy, reporting requirement or reinsurance arrangement and onboarding becomes another IT project, the organisation has automated a set of captives rather than built a scalable captive-management capability. The more useful growth test is whether the manager can move from 20 to 40 captives without doubling the operational team.

Specialty insurance shows the same pattern when each new line of business brings different quotations, referrals, wordings or binding logic. The effort required for that launch reveals how far the original capability can travel.

AI exposes the gap quickly. A document-extraction pilot may demonstrate high field-level accuracy while production still has to validate and map the output, route approvals, manage versions, account, report and audit. Strong model performance does not make the surrounding operation scalable.

The next-change test

Scale readiness asks whether the innovation is ready to expand. After go-live, the next-change test asks whether industrialisation has actually created reuse:

• How long would the next product or programme take to launch?
• How much new development would it require?
• Can another entity operate on the same core model?
• Can a new workflow be configured within existing controls?
• Can the next capability connect without redesigning what already works?

The answers to these questions expose hidden dependencies such as duplicated data, parallel processes, hard-coded rules, manual reconciliation or specialist teams that have to return for every change.

Genuinely new capabilities, major regulatory shifts or different business models may still justify deeper engineering. The signal to watch is whether expected growth follows a controlled path and leaves the existing operation intact.

The economics of repeatability

The real ROI of industrialisation emerges across later use cases: cost and time per new MGA programme should fall, the next specialty line should reach market faster, and a captive manager should grow the portfolio without headcount rising in direct proportion to the number of entities.

Across all three, the practical measures are cost per new programme, operational cost per captive, time to launch the next line of business, and development effort per expected change. Each should improve as reuse compounds.

The bigger opportunity

The bigger argument goes beyond the familiar claim that insurers are poor at scaling pilots. Insurance innovation has largely been designed as a search-and-test capability; the scarcer capability now is organisational change.

AI is accelerating that shift. Scouting technology, analysing suppliers and identifying use cases are becoming easier. Advantage moves to organisations that can identify an important problem, prove the value of a better approach, absorb the change and repeat it elsewhere.

Designing PoVs backwards from the conditions required to scale is where that capability starts. It turns the successful pilot that quietly stalls from a late surprise into an explicit decision made with evidence and ownership.

The winners will not be the insurers that discover the most innovative solutions. They will be the insurers that become best at absorbing them.