Your pilot is halfway through and nobody agrees what it has to prove

• The symptom: three people, three definitions of success
• The usual explanation, and why it does not hold
• What failed: legitimacy and predictability at the validation stage
• How to check this in your own organisation
• The structural response
• Conclusion
• References

Pilots rarely break over open disagreement. They weaken because the goal, the criteria and the mode of engagement were never stated out loud.

The symptom: three people, three definitions of success

It is week six of a twelve-week pilot. The review call is friendly, the demo works, the partner has shipped what they said they would. Then someone asks what has to be true at the end for this to continue. The innovation lead says the technology has to fit the existing stack. The business owner says it has to show a number. The partner says the pilot is there to learn what the real requirement is. All three answers are reasonable. None of them was written down in week one.

This is the middle of the Innovation Flow, the stage our second study calls Translation. Pilots, proofs of concept and prototypes sit here, and their job is to test assumptions and refine problem and solution fit before an implementation decision is taken. The stage has its own failure mode, and it is quieter than the ones on either side of it.

Our interviews are direct about how it starts. Collaboration at this stage rarely breaks because of open disagreement. Alignment weakens because the problem definition, the pilot goals and the evaluation logic remain only partly articulated, and everyone proceeds on their own reading of them.

“We often jump too quickly from first contact to pilot, without really aligning on what problem we are solving.”
Innovation Lead · Logistics · Netherlands · Global Operator

The speed in that sentence is not carelessness. Getting into a pilot quickly is usually a sign of a healthy organisation: someone decided to test rather than to deliberate. The cost arrives later, when the same pilot has to be judged and there is no agreed standard to judge it against.

The usual explanation, and why it does not hold

Two accounts circulate when a pilot goes vague in the middle, and each one blames the other side of the table.

The corporate version says the partner is immature. They want to iterate instead of delivering, they keep changing what the solution does, and they cannot answer basic questions about reliability. The partner version says the corporate is slow. Decisions take months, five people have to be convinced, and by the time a continuation decision arrives the company that was supposed to benefit has moved on.

Both descriptions are accurate and neither is an explanation. Our second study frames the underlying condition as an expectation paradox: corporates search for novelty but evaluate predictability, while startups seek fast validation but must prove reliability and operational fit. That tension is structural. It is present before either party does anything wrong, and it does not resolve by one side becoming more like the other.

The timing gap deserves particular care, because it is the part most often mistaken for a fault. One interviewee put the asymmetry in a single sentence.

“We did all of the work… in four weeks, but it was going to take them 18 months to get to change in production.”
CEO / Sales & Innovation Lead · IT Services · Finland

Figure 1. The two durations described by one interviewee, drawn on a single scale. Source: Bridgium, From Discovery to Practice (2026), section 6.1.

Our study is explicit that a gap of this shape should not always be read as organisational slowness. In regulated and asset-heavy sectors, long implementation cycles reflect structural constraints rather than weak commitment: certification, safety cases, OT and IT security, production continuity, and asset lifecycles measured in decades. A four-week build genuinely can take eighteen months to reach production, and nobody in the chain is dragging their feet.

What follows from that is a distinction both sides need and rarely make. Some delay is avoidable and comes from unclear process. Some delay is the sector, and no amount of goodwill will compress it. Treating the second kind as a motivation problem produces exactly the conversation that damages a pilot in its middle weeks: one party pushing for speed that cannot exist, the other defending a timeline it did not choose.

What failed: legitimacy and predictability at the validation stage

The Innovation Flow framework names four conditions that determine whether work keeps moving: legitimacy, predictability, connectivity and innovation memory. At the validation stage, two of them carry most of the weight, and they fail in a way that is specific to this stage.

Legitimacy here is not about the innovation function or about the budget. It is about whether experimentation itself is recognised as a valid organisational activity. Our study finds that startups seek space to iterate and adapt as they learn, while corporates often evaluate pilots through implementation-oriented expectations associated with mature vendors. The consequence is precise: exploratory solutions lose legitimacy before the problem and solution fit has been developed.

“We tend to evaluate startups as if they were already established vendors.”
Procurement Lead · Telecommunications · Sweden

Predictability fails alongside it. Our second study finds that when pilot goals, success criteria, ownership or decision pathways remain unclear, the collaboration becomes difficult to coordinate and sustain. Four mechanisms produce that state, and they are separable in practice.

The mode was never declared

The report draws one distinction as the decisive one: whether the collaboration is meant to explore and shape a solution, or to embed a ready one. Where that is unclear, both sides evaluate the same pilot by different standards, and each believes the other has changed the terms. This is the cheapest thing on the list to fix and the most commonly skipped.

The problem was stated partially

Corporates operate with real priorities and constraints that remain largely internal. The partner adapts a solution to an organisational context it only partly understands, while the corporate evaluates that solution without having exposed the operational priorities the evaluation is based on. Nobody is withholding anything deliberately. The information simply never had a moment where it was due.

Two communication logics, no translator

Partners communicate through product capability, technical possibility and future potential. Corporates frame evaluation through business cases, integration requirements and risk reduction. Our interviews record the effect from the corporate side.

“Difficulty in translating technology into business… especially when they focus too much on technology rather than business application.”
Innovation Leader · Industrial & Technology Systems · Finland

Under these conditions communication becomes continuous translation, and the translation work is assigned to nobody. It gets done by whoever has the patience for it, or it does not get done.

Feedback loops that never synchronise

A pilot rarely involves one unit. Innovation teams, procurement, operational departments, technical experts and the external partner all take part through different institutional logics. Without a mechanism that connects those perspectives, pilots stay local experiments instead of organisational learning. Our study is careful about the conclusion this leads to. The slowdown comes from problems, solutions, validation criteria and decision pathways that were never stabilised in a form all parties can read the same way, and it happens while interest on both sides remains high.

The requirements that follow from the four conditions apply to both sides of the table, and the report sets them out directly.

Table 1. Requirements for effective translation-stage collaboration by Innovation Flow condition. Source: Bridgium, From Discovery to Practice (2026), Table 4, section 6.6.

The academic reading

Karl Weick’s account of sensemaking describes what a pilot actually is at this stage. Our study calls pilots processes of collective sensemaking, where expectations, meanings and operational relevance are negotiated rather than measured. Weick’s point is that people commit to an interpretation and then act as though it were the situation. Two parties who never compared interpretations will each behave consistently with their own, which is why a pilot can look healthy from both sides while heading towards different conclusions.

Arthur Stinchcombe’s work on the liability of newness explains the evaluation problem. A young organisation lacks the track record that established suppliers use to demonstrate reliability, so applying a mature-vendor standard to it does not test whether the solution is good. It tests how long the company has existed. James March’s distinction between exploration and exploitation covers the last part: the returns from exploitation are nearer and easier to attribute, so an organisation under pressure will drift towards judging an exploratory pilot by exploitation criteria without anyone deciding to do so.

How to check this in your own organisation

Five questions. The first is the diagnostic, and it takes about ten minutes.

First: ask three people involved in a running pilot, separately, what has to be true at the end for it to continue. If the answers differ in substance rather than in wording, the pilot has no shared standard, and whatever it produces will be assessed against three private ones.

Second: is the engagement mode written anywhere? Co-exploration and ready-to-embed carry different evidence requirements, different timelines and different internal owners. A sentence in the brief settles it.

Third: what did you tell the partner about the constraints that will decide the outcome? Not the strategy, which stays internal, but the operational priorities, the integration reality and the compliance gates that any solution has to pass.

Fourth: which of the long timelines in this collaboration are sector constraints, and which are process? Write the two lists separately. The first list is a fact to be planned around; the second is work you can actually remove.

Fifth: who, by name, receives feedback from procurement, operations and the partner, and in what forum do those three meet? If the answer is a series of separate conversations, the pilot is generating interpretations rather than learning.

Table 2. Mid-pilot symptoms and the checks that separate a capability problem from an alignment one. Source: Bridgium analysis based on From Discovery to Practice (2026), section 6.

The Nordic dimension

The advantage is the ease of starting. High trust and short internal distances mean a pilot can begin on the strength of a conversation, without a procurement cycle in front of it, and our interviews show organisations moving from first contact into a pilot quickly.

The risk is produced by the same trait. Where a pilot can start informally, the criteria are the thing most likely to go unwritten, because writing them down feels like bureaucracy imposed on a relationship that is working. The looser the entry, the more weight sits on an agreement nobody recorded, and the harder the conversation becomes in week six when the pilot has to be judged.

Noted as an inference. Our study does not separate its Nordic respondents from the rest of the interview base, so the pairing above is read from the interview material as a whole rather than from a regional cut of the data.

The structural response

Our study frames the corporate task at this stage as creating protected space for experimentation before implementation logic takes over the process. Four steps do that, and all of them belong in the first week of a pilot rather than the last.

1. Declare the mode before the pilot starts. One sentence stating whether this is co-exploration or the embedding of a ready solution. It sets the evidence standard for both sides and removes the most common cause of mutual disappointment in the middle weeks.
2. Write the pilot goal and the validation criteria into the brief. Transparent validation criteria and visible decision pathways are what allow a partner to adapt and allocate its limited resources, and what allow your own units to judge the same result the same way. Three lines are enough: what the pilot must show, who decides, and by when.
3. Bring procurement, operations and compliance in during the pilot. Early alignment between innovation, operational, procurement and business units reduces fragmentation and improves continuity between exploration and the adoption decision that follows. Late entry turns those functions into obstacles; early entry makes their requirements part of the design.
4. Separate sector time from process time, in writing. Name the constraints that cannot move, and commit to the ones that can. This is the single change that converts an argument about pace into a plan, and it costs one honest conversation in the first week.

None of the four requires additional budget or a longer pilot. They change what is agreed before the work starts, which is the only point at which agreement is cheap.

Conclusion

A pilot is usually described as a technical test, and that description is what causes the trouble. The technical part is generally the part that works. What is being tested in the middle weeks is whether two organisations running on different clocks, each answering to its own internal audience, can arrive at the same reading of the same result.

That reading cannot be produced at the end. It is assembled during the work, from criteria that were stated early enough to be argued with, and from a mode of engagement that both sides named before anyone invested in it. Where those exist, a pilot that fails still produces a clear decision and a usable reason. Where they do not, a pilot that succeeds technically can still end in a conversation nobody can conclude.

So the question worth asking about the pilot running in your organisation right now is a small one. If you asked three people separately what it has to prove, how close would the three answers be?

The findings above come from From Discovery to Practice: How Corporate–Startup Collaboration Becomes Usable (2026), a Bridgium study based on 48 interviews with corporate innovation leaders and startup founders across Northern and Central Europe.

Section 6 covers the translation and validation stage in full, including the requirements table reproduced above.
The report is available at bridgium-research.eu/startup-report-2026/

References

1. Bridgium, From Discovery to Practice: How Corporate–Startup Collaboration Becomes Usable (2026), section 6 and Table 4.
2. Bridgium, How Innovation Happens: Insights from Leading Enterprises in Times of Change (2026).
3. Weick, K. E. (1995). Sensemaking in Organizations. Sage.
4. March, J. G. (1991). Exploration and Exploitation in Organizational Learning. Organization Science, 2(1).
5. Cohen, W. M. & Levinthal, D. A. (1990). Absorptive Capacity: A New Perspective on Learning and Innovation. Administrative Science Quarterly, 35(1).
6. Granovetter, M. S. (1973). The Strength of Weak Ties. American Journal of Sociology, 78(6).
7. Kerr, S. (1975). On the Folly of Rewarding A, While Hoping for B. Academy of Management Journal, 18(4).
8. Berger, P. L. & Luckmann, T. (1966). The Social Construction of Reality. Penguin.
9. Nonaka, I. & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press.
10. Burt, R. S. (1992). Structural Holes: The Social Structure of Competition. Harvard University Press.
11. Knowledge loss and employee turnover, Part I. The Learning Organization, 30(2).
12. Stinchcombe, A. L. (1965). Social Structure and Organizations. In J. G. March (ed.), Handbook of Organizations.